World: r3wp

In which case APPLY with math ops is kind of lame compared to scheme.

how does scheme understand to continue grabbing values?  because 
its not hitting an action?

or because it servers args within an argument () ?

I APPLY was simply implemented as the DO translation; you will get 
tons of side effects. Because,


APPLY :+ [1 2 3 4] implented as DO [+ 1 2 3 4] ;== 4 (NOT 10 wich 
is the expected result).

Because in Scheme you can have function with variable number of arguments 
thanks to the parenthetical notation. (APPLY + '(1 2 3 4)) ;== (+ 
1 2 3 4)  and '+ is coded to handle variable arguments.

In scheme the parenthesis tell the function where the expression 
ends. In rebol the number of arguments tell the function where the 
expression ends. This is a very fundamental difference and the tradoff 
made when dropping parenthesis or any kind of expression delimiter.

exactly.

but we can just implement our functions with a single block argument 
if we wish... then its a moot point... no?

No. Because now you need to be passing blocks everyware. And doing 
composing for symbol to value replacement everyware.

For example:  1 + 2  becomes + [1 2], and then how you handle + [a 
b]. You need a prebinde code. Basically that reitroduces parens.

yes obviously, actually calling reduce all the time.

I've often wondered if I missed variable args, and it seems I don't 
miss them that mutch.  they seem less needed in rebol.

but refinements are hard to reapply.

which is why I then use blocks as above.

I guess it could be nice if the burden of calling reduce where on 
the function itself.

I actually like the ability of having variable args. It is very handy.

in the example of a function which accepts one variable length block, 
it could cause the prebind (reduce) itself as a pre-entry operation.

in this case it would allow a parens-like calling method, but we'd 
use blocks and the caller would not need to reduce the value explicitely.

obviously, the function args spec would have to be expanded a little.

(apply * (map + item-order-list  item-price-list)) for example (apply 
* (map + '(1 2 4) '(100 50 25)))  ;== 300

That is my one line scheme code for totalizing an order.

But if function pre-bind blocks or pre-reduce, you lose CODE-AS-DATA, 
beside making function evaluation slower.

I used such technique in my toy implementation for supporting  multimethod 
. (Found in rebol.org)

BTW. The totalizing onliner above have '* and '+ switch. Damm dyslexia.

but that step is inevitable at some point even if we added parens. 
 because of the way REBOL does its binding no?

It could be replace if for example SPACE was use as delimiter.

Or maybe  a single DOT

or.... an yet unused char !!!!     a simple comma.

but then we get code like C with line terminations ... yuk.

Exactly. The curses of *free form*.

I actually think BLANKSPACE is a good candidate.

But thinks like append "d" copy skip "cba" 2. Need to be written 
in multiple lines.

APPEND "d" \
   COPY \
      SKIP "cba" 2


Using the '\ as hint that the expression is expecion something to 
return from the next expresion.

you are tooo scheme infected.

Nah. You alwasy do tradeoffs in Language Design.

;-)   for my part... REBOL's code looks are a reason I like it.

one reason I'm not attracted to what I've read of scheme is the actual 
syntax.

hehe

Actually scheme is pretty much free form; after using it for a while 
you no longer see the parens. Python removed the parens but forcing 
identation. Acutally there is a scheme mode that allow you to program 
without parens.

But the issues of expression determination is faced by every language. 
C uses Semicolons,, Scheme uses Pares, Unix Shell use Pipe and others; 
and Rebol argument counting. This simple principle will determine 
what kind of expressions are possible and what you gain and what 
you lose.

but I think just using the \ char should be enough each \ ends one 
var arg counter.

lifo ordering of arg "grabbing" should be able to determine which 
\ ends which func... AFAICT

First I thought R3 alpha will be released before the end of the year, 
now I wish we could at least see long time promissed diagrams of 
R3 architecture as a Christmas gift :-))

Pekr ! where is that negative tone I've come to love !     ;-)

ah, and I already thought, that I am being too negative even stating 
above :-)

for me R3 is inevitable, so far sounds good to me ... look - I waited 
for such architecture change since the beginning :-)

we almost always agree on most of the issues within R2 so I can't 
agree more!

I no longer await and I have been happy since then ;-)

who says we're waiting  ;-)

Jaime, I realized just now that it would be very easy to add variable 
args useage in rebol.  without any new symbol or "trick"

if functions had a refinement which said /grab or /varargs  then 
we could simply let the function grab all the values until it hits 
a wall (the end of a paren or block)