[EMAIL PROTECTED] wrote:
> Gabriele wrote:
> > > But then again you need the compiler in the runtime; I have doubts that
> such a "REBOL compiler" could be dramatically faster than the current
> interpreter. If you, instead, express the speed critical parts with an ad
> hoc designed compilable dialect, and then compile those, you get a dramatic
> speed improvement with just a little effort.
>
> pekr wrote:
> > sounds interesting, is it achievable? What would such "dialect" look like,
> what exactly should be its purpose? Could you explain a little bit, please?
>
> I could imagine an assembler dialect something like:
>
> stuff: 1234
>
> ASM [
> lda Stuff
> add 1
> ...
> ]
but such code is not multiplatform then. You can implement above using /Command
and its /Library component. I like Tao technology - Virtual Processor code,
abstraction over CPU. :-) Our VP is entire REBOL executable. I think Gabriele
thought of anything else - some rules to make our code compillable or something
along the lines, but no platform dependant...
Let's just add compile dialect (whatever it means, but not breaking platform
independency :-), together with tasking, modules, also add some funcs to perform
some matrice operations upon image! datatype to view to have faster & many more
effects, allow us to combine (load upon request) components (e.g. Command &
View), simply concentrate more on core technology ... and ... we will be ahead
...
-pekr-
>
>
> That could be interesting in Rebol/Command, arbitrary binary code in a
> script.
>
> Andrew Martin
> Not Gabriele...
> ICQ: 26227169
> http://members.ncbi.com/AndrewMartin/
> http://members.xoom.com/AndrewMartin/
> -><-
