World: r3wp

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 ....

... at least surrounding layers ...

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.