World: r3wp

2.7.2 it was:
http://www.rebol.net/upnews/0008.html

the change to switch was a good thing... wasn't it also mezz code 
a wee back?  IIRC this happened at the same time... and it made A 
LOT of code much faster.

>> - 2 + - 2
** Script error: - operator is missing an argument

is that in R3?

in R3, the - operator is not unary

or should we say, there is no unary version of the - operator?

That is false, actually

what is false?

what you wrote

in R2   -  can be either, no?

in R2, the - operator is both unary and binary, and its arity is 
determined during interpretation

so what is the diferrence in R3?

in R3, the - operator is not unary

well, that means there is only the binary version of the - operator.

that is false, as I see it

tell me how :


there is no unary version of the - operator  !=   the - operator 
is not unary

(I'm trying to understand what you mean... really)

1) There are not unary version and binary version of the - operator 
in R2, there is just one - operator in R2, which is both binary and 
unary depending on the "situation"

2) The statement "there is no unary version of the - operator" may 
be true only if you state, that NEGATE is not a unary version of 
the - operator

ok, well, to me the negate function is not an operator, but I understand 
what you mean.

I wrote: "...which is both binary and unary...", I could have written 
"...which is neither binary nor unary, since it does not have fixed 
arity, its arity being dependent on the situation..."

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.