World: r3wp

yes. some way to do without get  is a must-have. and for get one 
can write  the code directly instead of going thu apply. I now prefer 
your version.

apply can be used for RPC, but it could also be used for wrapper 
functions, and in that case variables are much more common... however, 
i don't know if it is worth doing that in apply for optimization 
only.

eg: append: func [series value /only /etc] [series: tail series head 
apply :insert [series value only etc]]

i would be happy to just do a reduce or get in that case.

fine

So it is a beter way to pass refinements? Thats good :)

Ladislav, it seems to me that APPLY will be more often used in wrapper 
functions. Still, I can see your point about APPLYing to straight 
data. Your example of passing an unexamined block gotten over RPC 
seems like a security hole to me, if you can trust the source, the 
idea has merit.

The REBOL convention for this type of thing is to have the more common 
case (which I think will be wanting to get variables) be the default, 
and have the less common case by done with a refinement. The refinement 
that would fit in with the majority of REBOL functions would be to 
have APPLY/ONLY refer to the no-get case.

I definitely want to have refinements supported by APPLY somehow, 
and have said so. The current proposal doesn't specify how refinements 
would be handled. Wrapper functions would need these in particular.

thanks

Love the proposed enhancement to the GET function though. Even though 
you wouldn't need it for APPLY, it would be useful to have GET on 
a block  return a block of values, for other purposes.

passing an unexamined block gotten over RPC

 - the problem is, that you usually are able to examine what service 
 the client requires and whether he has got the right to ask for that 
 service. If that is checked and the service is secure, the presented 
 method is secure too

Hence the "if you can trust the source" comment :)

I did mean "but if you can trust the source" though.

security - if it is has no  link to to words with functions it can 
only trigger  errors because the data does not  match the spec.

apply and refinements - in Gbriele  example  refinementsare handled 
like normal variables.

 append: func [series value /only /etc] [series: tail series head 
 apply :insert [series value only etc]]
Here they get their values by position.

That's the way refinements are handled by the APPLY opcode of rebcode.

As for triggering errors, I would prefer that argument type mismatches 
to APPLY would generate the exact same errors that a direct call 
to the function would generate - that way you wouldn't have to document 
2 sets of errors.

I am not clear how GET on a block of variables would be different 
to REDUCE.

Is it that GET would be selective about which values to reduce ? 
ie. only word! ("variables") ?

How would this block be treated ?
[a b 1 + 2]

when speaking about the REBCODE APPLY, variables A and B would be 
examined to obtain their values.

but when speaking about my proposed GET change, the block should 
contain only variables, similarly as the SET block is allowed to 
contain only variables

GET versus REDUCE: there is a difference. When a variable refers 
to a function, REDUCE evaluates the function, while get just obtains 
the function without evaluating it.

Ah now it makes sense.

GET sounds good to me.

hmm, almost 2 months from latest R3 related blog. And only 3plus 
months to DevCon ... I wonder if we will see running alpha at least? 
:-)

Carl is not writing blog, so he's writing code, that's good, isn't 
it? :)

if he is writing code, then yes, of course :-)

a couple of new blog entries discussing ++/-- and ranges

In the comments about ++/--, I suggested a new way of defining arguments 
to functions:

>> mult2: func [value:] [value * 2]
>> mult2 4
== 8
>> a: 3
>> mult2 a
== 6
>> a
== 6

With this addition to the language, INC could be written:

inc: func [value:] [value + 1]


Of course it would be better to have INC native, but with my suggestion, 
it will be possible to make our own functions, that works like INC 
and DEC.

What do you think?

is an extra  get /set that much effort?

but  i dont  like  funcs that  way. i read a and think  it is  evaluatet. 
leads  to confusion.

Volker, maybe not. But then we should just stick with

a: a + 1

shouldn't we?

if  it  looks like an operatorthat say  "exception"

but i prefer    a: + 1

or     inc 'a

a:  -  1 ; disambigius.

Volker, I follow you. Our normal way of thinking about functions 
and lines of code in REBOL is, that if we see a word, and we recognize 
it as a function, we look for arguments after the word. And we wouldn't 
think, those arguments would be changed. If words (variables) change 
value, we expect a set-word (like a:). Conclusion might be, that 
my suggestion will probably lead to more confusion. Falling back 
to ++/-- (or INC/DEC), those might be confusing too.

Problem with

a: + 1


is, that the plus sign can be seen as a unary plus. Because what 
should this mean?

a: + b

Same with unary minus as you point out.

yes, but if we think c,   += and  -=  are  a close accosiation.

unary + makes no  sense.  unary minus makes, thatis a  problem.

a+: 1
maybe?

Not good, because a+ is a valid word.

or  without space,  a:+  1

but these break syntax.

hmm yes ... and yes.

although, an operator-word! as datatype?

argh, it's hard to define a language! :-)