r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Henrik
25-Jan-2007
[1850]
>> make money
** Script Error: money has no value
** Near: make money

BrianH, Rebol doesn't care. :-) Just a joke.
BrianH
25-Jan-2007
[1851]
Hey, I miss you guys :)
Pekr
25-Jan-2007
[1852x3]
:-)
well, looking at R3 architecture doc, we can start porting to Java, 
.NET ....
... at least surrounding layers ...
BrianH
25-Jan-2007
[1855x2]
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.
Pekr
25-Jan-2007
[1857]
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 ...
BrianH
25-Jan-2007
[1858]
I have been quite vocal in my opinions about my interests (read: 
pet peeves) so far :)
Henrik
25-Jan-2007
[1859]
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?
BrianH
25-Jan-2007
[1860]
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.
Pekr
25-Jan-2007
[1861]
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
BrianH
25-Jan-2007
[1862]
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 :)
Pekr
25-Jan-2007
[1863x2]
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?
BrianH
25-Jan-2007
[1865x3]
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...
Maarten
25-Jan-2007
[1868]
L: I agree with your get/apply proposals
Ladislav
25-Jan-2007
[1869]
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 [...] ?
Volker
25-Jan-2007
[1870]
get needs to allocage a block.
Ladislav
25-Jan-2007
[1871x2]
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...
Henrik
25-Jan-2007
[1873x2]
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 :-)
Ladislav
25-Jan-2007
[1875]
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.
Volker
25-Jan-2007
[1876]
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.
Ladislav
25-Jan-2007
[1877]
...but even then everybody is going to have a hard time trying to 
supply a variable as argument
Volker
25-Jan-2007
[1878]
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.
Gabriele
25-Jan-2007
[1879x3]
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.
Ladislav
25-Jan-2007
[1882]
fine
Volker
25-Jan-2007
[1883]
So it is a beter way to pass refinements? Thats good :)
BrianH
26-Jan-2007
[1884x3]
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.
Ladislav
26-Jan-2007
[1887]
thanks
BrianH
26-Jan-2007
[1888]
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.
Ladislav
26-Jan-2007
[1889]
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
BrianH
26-Jan-2007
[1890x2]
Hence the "if you can trust the source" comment :)
I did mean "but if you can trust the source" though.
Volker
26-Jan-2007
[1892x2]
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.
BrianH
26-Jan-2007
[1894x2]
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.
Anton
27-Jan-2007
[1896x3]
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]
Ladislav
28-Jan-2007
[1899]
when speaking about the REBCODE APPLY, variables A and B would be 
examined to obtain their values.