World: r3wp

Carl has a point though.  Orca needs to be BETTER than Rebol, or 
at least as good.

I didn't pay RT $1200+ to help develop Rebol.  Forget that noize.

Jaime thanks for asking...But there's not a simple answer.

The point I am about to make applies to any proposed variant in ORCA 
vs REBOL.


The problem with changing fundamental behaviour is that it makes 
it hard to port applications: think a few years ahead when ORCA is 
a fully operational REBOL clone, and (as an example) (unlike REBOL) 
runs on PDAs. I'd like to use ORCA so I can run an application in 
a PDA; but I want to use REBOL for all my other platforms. And I 
don't want to have to pick through code and/or support two source 
versions because of avoidable differences in behaviour.


On the other hand, an ORCA-only application might benefit from the 
"more correct" implementations of basic operations.


One possible way to square that circle is to have a set compatibility 
flag:
    system/orca/xor: false  ;; gets me REBOL XOR behaviour

I just have to wrap that in an 'attempt and I can keep a common source 
that will run under either.


[I appreciate that there may be performance issues doing it that 
way -- may be better to have compatibly options specified in an orca.r 
file that is only processed at start-up....I'll leave the details 
to the people doing the design]

I vote 1.7.3

But as Sunanda said, compatibility should win, and may I suggest 
deviations should be "extra parameters"

Sunanda. I fully agree, and the reason for my asking. I will wait 
for a bit more input before deciding which route. An solution is 
to create rebol-compat mezz. That way you get the best of both worlds.

With only a penalty in performace for backward compatibility, specially 
when it is about correctness.

Terry, Out aim is to make Orca better than rebol, but first we must 
catch on ;-)

Joe, Both Dockimbel and Frank know about hte orca project and may 
decide to contribute, the project is open to anyone willing. I believe 
they are tied up with other commitments and may have their own plans 
for their clone efforts. I am interesting in collaboration and pragmatics, 
more that discussions. So Orca is open to anyone willing to collaborate 
;-)

I hope to see more skilled C programmers jumping at any point. But 
need more than programmers and designers. We need people documenting, 
testing, creating regresion tests, optimzing, etc.

Maybe some of these folks can help out on the open modules that are 
part of REBOL 3.0 too. And, we could always use more tests, etc.

I hope there is a lot of cross-pollination.

IIRC Doc did not planned to be 100% compatible either. IIRC he wanted 
to introduce two layers to networking. It comes from his experience 
when working with networking (Uniserve etc.). I think that redesign 
is the right time for language to correct/improve some of concepts. 
I expect REBOL 3.0 to go that route. 2.0 was rewrite too.

IIRC even Carl thought about e.g. some View min-face layered concept, 
at least I do remember it from some blog article. And that is that. 
I am the one who is willing to redesign my few apps for 3.0, IF, 
of course, it adds significant improvements .... so the same goes 
for Orca. If we feel that we have something in Rebol what is limiting 
(conceptual wise), I, in opposite to Sunanda (although understanding 
his pov), am for incompatibility, if done for good ...

... well, but I am not a designer, nor I am in situaion having lots 
of REBOL apps to redesign ...

and you can always use your old 2.x SDK to improve on your apps .... 
having time to redesign for new branch (3.0)

maybe Carl could nowadays tell us something about REBOL 3.0, as some 
info is leaking here or there ...

<<A solution is to create rebol-compat mezz>>

I've suggested to RT a couple of times that REBOL needs a compatibility 
mode for behaviour changes  between its versions.

That would give Carl the freedom to change things (like reverse vs 
head reverse) while guaranteeing (more-or-less) that applications 
continue to work unchanged on newer versions of REBOL.

Perhaps the ORCA crew and RT could exchange ideas on such a mode 
so we don't end up with incompatible compatibility modes.

tuple + number in rebol makes sense IMHO:
!> gray + 30 ; lighter
== 158.158.158
!> 1.2.3 + 0.5 ; i can round myself. i can not deround
== 1.2.3
!> 1.2.3 + 1.1
== 2.3.4

Sunanda, <<A solution is to create rebol-compat mezz>> we have decided 
to provide a compiler flag for backwards compatibility; so you just 
need to recompile to obtain previous behaviour.  We may investigate 
mode switching in the future, but we don't want to carry the bloat.

.

Some stats

Timing test - parse 2000 int/decimal

  Parser                    Seconds
  ---------------------------------
  Thune (C)                 0.0008
  Rebol (built-in)          0.0044
  Thune (rebol-style parse) 0.0097   ; work done in ()
  Rebol (parse)             0.0228   ; Just parse - no ()

Timing test on Lua's fib test.

   Language       Seconds
   ----------------------
   Lua 5.0        0.14
   Thune          0.20
   Orca           0.36
   Rebol          0.80

Basics ops benchmark, measured using Ladislav time-blk tools, results 
in seconds:

;REBOL
;getword  0.08612
;setword  0.2006635
;funccall  0.194279125
;make-object  1.750536

;ORCA
;getword  0.072630
;setword  0.133684
;funccall  0.177569
;make-object  0.917472

BTW. I forgot to mention lowe r is better. So, in some instances 
Orca is two times faster than Rebol.

because it is doing less?

No. As you see the benchmark for basic ops shows that Orca is already 
faster in what the interpreter does the most.

So, Orca can now has a full parse implementation?

Pretty much. It is being fine tuned currently

Jaime, is this something that could be compiled for my Sharp Zaurus?

Probably

Hmmm. It's like Core?

It's part of Core, currently

Thanks.

But some things are also nicer. It's designed as an embeddable library

well it can open guis too, no... using QT?

Yes, on Linux. Hm, maybe on Windows as well

I'll have to try to carve out a bunch of time. I've never compiled 
anything on my Z. Sounds like fun though.

Good luck :-)

Thanks....I'll need it.

Yes. It produces GUIs in OSX too. But you need to install Qt.

Compiling in the sharp zaurus requires an GNU environment, and probably 
a boots trap m2->Makefile.

license question: would there be problems in running BSD or proprietary 
licensed scripts on a GPL based Orca?

GPL languages mean that the GPL only applies to the language and 
not scripts.

A GPL word processor does not write GPL documents

unless it includes some of itself in the document, right?

If a GPL word processor printed out the source of the GPL word processor 
?

lets say it includes macros which where part of the word-processor's 
scripting language.

There's a separate group for discussing the niceties of licensing 
:)