World: r3wp

3 ways? Does your cell phone run .NET? And what is the third option, 
a native rebol port?

btw - if we get Rebol ported natively to target devices, what do 
we get specifically by linking (or porting) it to .NET? btw - is 
it difficult to establish such an interoperability?

I think the existing WinCE ARM port of /Core 2.5.0 will run on it. 
But yes, the phone also has J2ME and .NET Compact.

As for interoperability with other VMs, for now REBOL either has 
to go for the lowest common denominator (C interfaces) or the highest 
(Web Services or other networking standards). Either way ends up 
being slow and awkward because of all of the marshalling and object-model 
translation involved, but that could all be simplified by making 
LNS shims for their RPC infrastructure.

Later...

L: I agree with your get/apply proposals

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.

 - I am not sure I understand what you have in mind - do you mean 
 you didn't like APPLY :f GET [...] ?

get needs to allocage a block.

I accept your refinement suggestion as a more optimal variant

...GETing and APPLYing would be faster...

 - well, I thought not, since we needed APPLY, not GET and APPLY...

Sorry, I meant explicitly doing that in mezzanine (which we want) 
would be a bit slower as opposed to doing it internally in APPLY 
(which we don't want).

oh well, not important :-)

APPLY usage discussion continuing


It is interesting, that BrianH thinks, that almost every call of 
APPLY will obtain a block of variables needing to be examined.

My envisioned usage is, that APPLY obtains a block of values sent 
e.g. from the Internet, where it does not make sense to sent a block 
of variables unless the variables are meant to be the arguments.

Good reason. And in that case auto-get disables to send words. apply 
would 'get them.

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

In that case gettin  would make sense. Or when using  apply from 
rebcode. If  Carl reuses the code there.

...but even then everybody is going to have a hard time trying to 
supply a variable as argument

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"