World: r3wp

Why don't you use synapse chat?  You have the server and client ...

Can you build that for all platforms ? Is the source open ?

Jaime, this is a deep difference and we need to settle it.  I agree 
it's more exciting being able to experiment and choose new behaviours 
for a language, but I think it's more responsible to support the 
language that we have. We can't just keep jumping from language to 
language. The real hard work is to perfect an existing language.

Will you agree to a real clone ? Then we can move forward without 
forking.

At least the same syntax. not intended breaks like using $ for hex 
because orca will not need money! anyway.

Why are you pushing ahead anyway since you say you have abandoned 
Rebol for plt-scheme and ror?

Jaime said hobby and learning. Maybe we should implement an rebol-interpreter 
in scheme?

What i am curious about, how does scheme handle binding? can i bind 
symbols in data to contexts, and how? I like that for dialects.

I would value Jaime's contributions highly, however, it's important 
that we don't fight each other by pushing different directions.

Sometimes you have to take a big step back to consider the issues.

Rebol exists, and works for most people given what they are trying 
to do.

The cool thing about an open source version is that when someone 
comes across a problem they can fix just that problem (thus offering 
it back to the community).  In theory this could be done in such 
a way that that section of Rebol runs on Orca (for example), while 
the rest runs on standard Rebol.


O Rebol can "choose" to fix these issues (since they would be self 
documenting).
O Orca can branch from the Rebol sheme.
O New features can come into existence by committee.
O Open source die-hards will step up to Rebol

O Some companies are anti-open-source.  Rebol then becomes their 
savior, and thus becomes closed version of itself.

This actually seems like a win/win to me.

yes, but maybe it would be vital, if FINALLY RT would explain a bit 
a plan. We saw documents about more of community involvement, also 
about how some parts will be opened. But what we never saw were details 
to such a plan. R3 is coming. My understanding is, that is should 
make situation much better, as what does not belong to kernel, should 
be kicked off from Rebol, into module/plug-in, call it whatever ...

If we get extensible R3, who needs open source just for the sake 
of open source? The only part closed will be the language itself 
...

but it HAS to work, otherwise I understand the concern of Jaime - 
waiting for fixes months is frustrating ...

Just don't expect me to join Google groups or anything. There are 
far too many disparate communication systems around. I have happily 
standardized on AltME

That's alright, we moved to IRC.

IRC is standard, but when altme is available, I wonder why that choice 
... but hey, whatever works :-)

Reichart, yes, the development of open source rebol clones may just 
allow Rebol to become comfortable with its closed position.

Pekr, AltME doesn't cover all linux platforms yet, so that would 
limit the audience a little bit.

but R2 is already dead anyway. R3 introduces lots of new concepts, 
I wonder if Orca will try to adapt ...

R2 is not dead. I am still using it ! It will be very useful for 
some time to come. It will take a long while for R3 to stabilise 
to the point at which R2 is now.

I expected exactly such a reaction, just waited for it to pop up 
:-) I am talking about focus/orientation .... all the potential of 
RT goes to R3. Judge for yourself, if Orca should, and for how long, 
to focus on R2, respectively to add new features, before we know, 
what RT gives us ...

I do love the dramatic statements around here sometimes...

well, it's not like R2 will become utterly 100% useless, is it? There's 
a ton of value in R2 still.

my opinion is, that Orca should stick to compatibility mode right 
now, before it is clear, what R3 offers on its own feature wise (tail 
recursion etc. discussed here), because later, if Orca now goes its 
own way, it may not be easily possible to get on pair with R3 compatibility 
wise ....

also my Rebol/View hasn't stopped working since R3 was announced...

I want Orca being Rebol compatible as much as possible, or it is 
different language then ...

Exactly. I agree with everybody forever.

of course, as I am not able to contribute, just regard my vote as 
not non important ... it is upon those who contribute to Orca ...

Anton :-)

not non = not so ....

Anton, I don't see contradiction between your goals and my goal.

Sounds good, but how about this case: 
	foreach v [1 2 3] [ ]
in rebol currently returns unset!
in orca returns 'v

It can be argued that this is a small useful improvement that doesn't 
interfere with rebol code. I would prefer, however, to change it 
back to the rebol way because there may be times (possibly very rare) 
when some code relies on this behaviour and is broken by the change. 
How do you see this case ?

Reverse it you want.

Ok, that's good. So when you want to add things to Orca, how can 
we manage that ? Compiler switch ?

Yep. There is already a compat flag.

Kaj, and anyone else new to the discussion, I'm trying to get a consensus 
on the future direction of Orca. It is a divergence from Rebol, as 
stated on these pages:
http://trac.geekisp.com/orca/wiki/OrcaProject
http://trac.geekisp.com/orca/wiki/OrcaBehavior

Look at op.c in the src code.

In Ruby it would return 3, which is actually very nice in many cases

But I would like to steer it back to Rebol. Actually, since Orca 
needs a name change, it's probably better to fork and do a big name 
change, probably to something like OpenRebol or ORebol. What do people 
think about that ?

Anton, search from "#ifdef LANG_ORCA
" if you want examples of use.

(Kaj, note the body block is empty.)

Jaime, ok..

Anton, I agree with changing Orca's course to be more compatible 
that it is now. On the other hand, I think it would be fairly silly 
to specifically implement REBOL bugs, especially now that R3 is going 
to fix some of them

Still, in Ruby it would return 3. :-) Which I use a lot

Actually, that's another issue:  Do we make a separate fork for R3, 
(considering it may not stabilise for some time.) ?

That seems like overkill. I say develop Orca along with R3, with 
the same features

It's not like the differences are huge - one of the advantages of 
the high abstraction level

But we don't know what R3 is yet.

We don't know what Orca's going to be, either :-)

I think we're talking details here