World: r3wp

then this would simply work DO [+ 1 2 3 4]   or apply :+ [1 2 3 4]

maybe the behaviour could then be toggled like a refinement on demand 
as an option when the use is not always mandatory  like so:

(sum/grab  1 2 3 4 5 5)

this makes all current code valid, and expands the functionality 
easily.  since its part of the function's description, anyone using 
it would just use it appropriately.

and in any case its still going to evaluate all the code till the 
end, so it won't even prevent code execution even if misused.

This doesn't scale well. The problem is what defines a wall. Actually 
that is the definition of delimiter.

The problem becomes inmediate in function composition.

What is the meaning of ?

f/grab h/grab t/grab 1 2 3 4 5

This type of composition appears a lot when using combinations of 
apply and map and fold.

Also /grab has diferent semantics than standard refinements which 
either expect 0 or 1 arguments.

why not just use a block argument?

Hi Jaime, it scales as well as in all other languages using varargs 
... of course you need to use parens to group args.

Hi sqlab, the troubel with blocks is´, that you have to add an additional 
reduce step in almost all cases ...

Ingo, but Max suggestions doesn't use parens. Just a refinement. 
Also in rebol parens escabe the interpreter and re-enter it. Slowing 
execution. I don't think see as a good fit.

Maxims approach is used in vid, where the wall is not the end of 
block but something "wrong". IE it could be standart to terminate 
such things with a dot.
  a: sum 1 2 3 4 .  print a

all needed would be a way to parse the callers code, i wish that 
for years. Other question is if is really is needed. blocks work, 
and the reduce can be done inside the function.

; works as a terminator.
I used it once for a function with many unset! arguments

sqlab, i'm not sure about that.

>> do {print ;something^/"bla"}
bla

I wonder if the lack of variable number of argument is the most needed 
feature for us?

nope

yes, it  works just until a newline.(

As for me, I never needed it with Rebol ....

I will agree that varargs is not the most needed for me the two that 
rank above the rest is that all functions are closures, second tail 
call optimization, and finally continuations.

With this three features a lot of possibles programming patterns 
are open. Like light multi-threading without needing to wait for 
some change in the C side.

I think this article explains the importance of having a truly extensible 
language using Dialects and Smalltalk .vs. Ruby comparison. http://onsmalltalk.com/programming/smalltalk/domain-specific-languages-ruby-a-sign-post-on-the-road-to-smalltalk/

weird article. Not a ruby guy, but have read: ruby can do smalttalk 
style if/else just as well; yiled is used in iterators, kind of continuations; 
continuations in squeak are a hack based on the low-level stack implementation.

hmm, I expected RT to at least say few words about how development 
of R3 goes. "REBOL projects and priorities" is once again off-base, 
and needs a bit of update ....

User poll:

In REBOL3 there will be a native APPLY function, as you may be aware 
of

currently Carl thinks, that it should not reduce the supplied argument 
block, but it does to a GET on variables

...but it does *do* a GET on variables..

my preferences differ, I would leave all values as they are supposing, 
that if there is a variable, then the function is supposed to obtain 
the variable, not the contents of it

What are preferences of you, REBOL users?

Hm not sure, but I like your approach more.

yes, I agree that it should not GET.

one more note regarding APPLY situation and my preferences. In addition 
to APPLY not doing GET on variables I would like to generalize the 
GET function a bit. It would be ideal if GET was a counterpart to 
SET and accepted a block of variables returning a block of their 
values. This way if we had a block of variables we could write: APPLY 
GET block-of-variables.

...or rather: APPLY :some-function GET block-of-variables, or some 
such

I agree

to reduce or not to reduce, that is the question. I have no clear 
answer myself, although I might prefer Ladislav's version too, if 
it allows more functionality. But generally speaking (not telling 
this is the case), if we will create some scenario, where 90% of 
usage will push users to add 'reduce word, because user wants it 
in those 90% of case, then reduced state should be reduced, or users 
will a) do mistakes not reducing themselve b) regard it being a bug 
c) use reduce automatically without thinking why is it needed :-)

I like your idea about GET. Your idea about APPLY sounds nice in 
theory, but in practice it would add a block allocation to almost 
every call of what should be a low-level, efficient native function.

Keep in mind that Carl has said that APPLY would be used to implement 
DO in REBOL 3 code.

hehe, now one question, maybe a stupid one - would it be technically 
possible, for functions which reduce by default (because in 90% of 
cases you want to reduce), to have some dont-reduce function in rebol, 
telling it to not reduce? :-) Not probably possible, because func-x 
[block of arguments] - there is no place in evaluation order how 
to order the func-x to not reduce the block? :-)

func-x [[block of arguments]]

heh, thanks :-) BrianH - you should cooperate with Ladislav and Carl 
more closely, as I feel you have something to say to deep Rebol knowledge 
.... especially you should opt for assistence with RebCode development 
(finishing of its development) :-)

ladislav, I suppose that GET'ing when APPLY''ing as standard, would 
be faster than doing it afterwards? It's probably faster, but less 
flexible.

'apply/only for ladislavs case?

Petr, I would be more than happy to, but I would neet to retrofit 
REBOL with support for more Microsoft technologies before I could 
use more at my current job. Much as I like REBOL, I like a salary 
too.

>> make money
** Script Error: money has no value
** Near: make money

BrianH, Rebol doesn't care. :-) Just a joke.

Hey, I miss you guys :)

:-)

well, looking at R3 architecture doc, we can start porting to Java, 
.NET ....