World: r3wp

Would people miss unary minus in R3?

Ladislav, do you mean "fixed parity"?


And yes, there seem to be just one minus '-' in R2. If you redefine 
- with something like:
	set '- ...
, then you don't have unary minus any longer.

'Ladislav, do you mean "fixed parity"?' - no, I did mean "arity", 
not "parity"

And, in R2, the - operator is, in fact, variadic, having neither 
arity 1, nor 2

I learned some new words, thanks! :)

Would people miss unary minus in R3?

 - Initial testers reported its lack as a bug. The bug was dismissed, 
 since this was an intentional change. The benefits of the reduced 
 ambiguity won them over once they got used to it.

variadic
 - nice, I love precise words :)

There is a trick in R3 for variadic functions, but it only works 
for the last arguments of a function, not the first, and only when 
the function is called at the end of the block/paren/script.
>> a: func [x [any-type!]] [type? :x]
>> a
** Script error: a is missing its x argument

>> a: func [:x [any-type!]] [type? :x]
>> a
== unset!

>> a: func ['x [any-type!]] [type? :x]
>> a
== unset!


The trick is to use a lit-word or get-word argument and allow it 
to accept unset! values. This is used mostly for console interactive 
functions like CD.

that's neat

In R2, the first example would work too:
>> a: func [a [any-type!]] [type? get/any 'a]
>> a
== unset!

But in R3 that behavior is being discouraged on purpose, to make 
code easier to debug, so the alternate argument types are required.

...lit-word and get-word argument...

 - please stop using that misleading terminology. The former is, in 
 fact a "partially evaluated argument", the latter is "unevaluated 
 argument". See the documentation.

...

lit-word argument would need to be an argument that is a lit-word, 
etc.

it's hurting noone

I'll try, but the alternative terms aren't precise enough for me 
to remember.

But the meaning is documented, so try to read the doc (it was Carl 
who documented it, not me)

Fair enough, I'll try. Those terms only work when you immediately 
follow them with code examples that display the precise meaning. 
Not a bad habit to stick to anyway :)

The declarative forms, like they are written in the specs of a function 
are trully lit-word! and get-word.
I don't understand why you get so upset about that

I prefer to think of them as designations rather than descriptions.

well, if a "partially evaluated argument" is declared via a lit-word... 
 I don't know why I wound't use the label instead of the definition.

This place is turning into a nit-picking place :-)

Exactly because a "lit-word argument" is an argument that is a lit-word, 
while an "unevaluated argument" is argument that is not evaluated.

Steeve, or a place ruled by religion.

If the notion wasn't confusing, I would be the first one to suggest 
to use it

Ladislav, all human languages are highly polysemous.

In the previous contexts, the words : "lit-word argument" may be 
deciphered as:
1) A passed  argument which is a lit-word (your point)
2) An argument that is declared as a lit-word (Brian's point)

The Brian's words are clearly meaningfull in this context, It's only 
you Ladislav who  decided that your personnal semantic representation 
was the only one possible. You couldn't be more wrong.

Or maybe I'm wrong ;-)

An argument that is declared as a lit-word (Brian's point)

 - again, an error. An argument, that is declared as lit-word looks 
 as follows:

    argument [lit-word!]


, while an argument, that is partially evaluated is declared as follows:

    'argument [any-type!]

Ladislav's terms are better, in the sense of being more descriptive, 
but I'm unlikely to remember them because I've been using the old 
designations for 10+ years. I'll try, but don't give me a hard time 
if I don't get it at first.

I use "an argument that takes a lit-word" for this:
    argument [lit-word!]

and "an argument that is declared as lit-word" or some variant for 
this:
    'argument [any-type!]

But the latter is ambiguous if you don't know that I only use it 
in that way.

Ladislav, in the sentence: "An argument that is declared as a lit-word" 
can only apply to 
 - 'argument [any-type!]

But it's ok if you say the contrary, I'm not good enough with enligh 
anyway, so I will not argue against that.

Ladislav, in the sentence: "An argument that is declared as a lit-word" 
can only apply to 
 - 'argument [any-type!]

But it's ok if you say the contrary, I'm not good enough with enligh 
anyway, so I will not argue against that.

Dou you speak Frenglish ? :-)

Not really :(

'Ladislav, in the sentence: "An argument that is declared as a lit-word" 
can only apply to 

 - 'argument [any-type!]' - interesting, why do you think so, taking 
 into account, that the meaning of "an argument that is declared as 
 a lit-word" is pretty much standard in many contexts (programming 
 languages), not just in REBOL

Not really - they say that about variables, but for arguments that 
is considered an ambiguous term, depending on which proglang community 
you're talking about of course.

How about all programming languages descending from ALGOL including 
C?

(for me it does count as "many contexts")

In the English papers written about such languages, the phrasing 
is inconsistent (it is English, so that's to be expected), and there 
are cultural patterns in the communities associated with different 
programming languages, colleges, etc. There is no really consistent 
phrasing for this distinction.

Which distinction you mean?

Thanks Ladislav,  I know my job very well but I continue to think 
that you're only arguing about: 
- This idea can only be expressed my way with my words.  

You don't recognise the simple fact that same words have different 
meaning inside different contexts.
Vernacular languages are polysemous, it's a fact.

Good point Brian

Which distinction you mean?

 - Between a calling convention and a datatype, if the terms overlap. 
 Between the type of a variable, the type of a value, and the set 
 of types accepted by a function parameter, in languages where these 
 concepts are distinct. There's lots of subtle distinctions that need 
 to be made, and for many languages some of these distinctions are 
 different, tied to the particular semantics of the language. REBOL 
 has it worse than most because it's weird when compared to most mainstream 
 languages.

This idea can only be expressed my way with my words.  

 - an error, again. This is not about "my words", this is about the 
 official documentation. You are free to not read it, and argue it 
 does not even exist, but that is not an argument for me

The official documenbation  suffer the same bias. You're reacting 
like a monk in front off the holy bibble.

suffers the same bias
 - do not understand what "bias" you mean

It's nice to have an official way to express a concept, but that 
doesn't help much if it isn't the common way that the community uses 
to express that concept. It doesn't help to refer to the manual if 
that manual has been rewritten since the last time the person you've 
been talking to needed to read it. Accept that there are community 
standard terms, and hopt that the better terms in the manual win 
out eventually, or at least before the manual is rewritten again 
with even better terms.

To add more confusion to the mix, lit-arg(ument) and get-arg(ument) 
worked fine as terms in the past :)

hopt -> hope

the bias of having english words which can express several different 
concept