World: r3wp

Any time I am on AltMe is break time for me. Most of what I do with 
REBOL nowadays is parse and file manipulation, and neither of those 
have changed much in years. I don't need View - most of my code is 
non-interactive or web-based.

As for .NET and Java, that kind of interoperability is why I was 
so active in the discussion of R3's object model.

so visit here from time to time and please if you have something 
to say to the topic, feel free to. I believe Ladislav and Carl listen 
to various opinions ...

I have been quite vocal in my opinions about my interests (read: 
pet peeves) so far :)

I'm wondering a bit how general the closed core will be? Will it 
be only CPU dependent or delivered as an object for linking against 
upper and lower layers?

That is an interesting question. I guess it depends on how serious 
Carl was when he was talking about transitioning RT's business model 
more towards services and partnerships. If RT goes that way, then 
they are less likely to limit the tools.

Henrik - that is the question - but even an object is not portable 
across platforms automatically, no? RT would always had to "recompile" 
and in the case of Java or .NET host environments, to port to Java 
and .NET

Even though I have been more in favor of interoperability than of 
reimplementation, that does sound good. If the REBOL core were implemented 
on .NET and Java, I would have 3 ways to run it on my cell phone, 
not including WildMan :)

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? 
:-)