World: r3wp

rebol is not compilable because it can express things that a compilable 
language cannot express.

if you are willing to give up the advantage in expressivity, you 
can just use a compilable dialect and compile to rebcode or even 
C etc.

also keep in mind that 90% (or maybe even 99%) or rebol scripts that 
people write could be compiled, as they don't take advantage of 100% 
of rebol

(but I guess that 80% of my scripts are not compilable ;)

hotspot can compile code which changes later, so i am not conviced 
:)

i think self and its "childs" could do it.

Err... most of my code surely cannot compile either :)

Remember, too, that REBOL is not first and foremost a programming 
language. If that had been the main goal for REBOL, I have no doubt 
that Carl would have designed it to be compilable, and probably provided 
a compiler from the beginning.

I still think that most of my code is compilable - you just need 
to think about the semantics in the right way.

Its compilable if some of the info is gathered on runtime IMHO. Maybe 
with the option to switch back to the intepreted code, to solve gabireles 
changed 'if.

One of the tricks you would need is to realize that there is no "REBOL" 
language. Each dialect is semantically a seperate language, with 
a different execution model. You can't treat REBOL data as a particular 
dialect until you know which one, and you often don't know until 
runtime. Because of this you would have to compile at runtime, or 
at least function build time. Any attempt to compile ahead of time 
would change the semantics, in a similar way to how prebol does.


Even at runtime the semantics would be different, but not as different 
as you think. Few people realize that while the DO dialect looks 
a lot like a Lisp or Scheme clone, its underlying semantics are quite 
different - and yet they still are able to program in REBOL just 
fine. You could change the underlying semantics to a completely different 
model and keep all but the most guru of programming similar enough 
that most people won't notice the difference. The only main change 
would be to make the code blocks of compiled functions unchangeable 
once the function is built - so no more patching running code.

Don't expect too much of a speedup though. REBOL is really fast already, 
and runtime compilation has some overhead itself.

Yes, compilation must be done on block-level, and preferably after 
the block has already been interpret. to find function-boundaries. 
but self could go half as fast as c, and hotspot even faster. while 
switching back and forth between compiled and interpreted code.

and for scripting there would be a slowdown, except if the vm could 
store the results of the compilation as exe, with the original interpreter-code. 
kind of quick loadable memory-dump.

(dont ask me how that works, i only know some system can do it)

Volker;  Thank you.  Your parsing data code made me and REBOL look 
like heroes

today.  :)  Another happy boss, less afraid of his computer.  We 
all win.  Thanks!

I really would like to see some of my functions compilable, using 
rebcode or something else... Since I'm now working on a new version 
of my rebol/flash dialect, I found very difficult to bind functions 
into another (recursive) function's context. At this moment I still 
have to define these "inside" functions in the recursive function 
always when I call it, so it must be slower. Maybe it would be enough 
form me, just to have some more easy and fast way how to get such 
functions into specified context. But maybe I just have bad approach.

(f a b) *must* be quoted or be in a quoted list (maybe using the 

funny" way of quoting available for macros ;) for it not being a 
function call." This is simply not true. Not with syntax-case macros. 
You need to know that Scheme Macro system is different and a lot 
better than the one used by lisp as pointed by the article.

See example 6. That introduces a macro for setters and getters, and 
depending the position of the variable it behaves one way or another.

I don't think the compilation of Rebol language has anything to do 
with CPU features. But CPU are algorithms in silicon, so maybe you 
could in the future expedite branch searching.

And regarding quotation, every block in rebol is quoted in the sense 
that it is just data. It only acquires meaning when passed thru some 
form of evaluation. Like DO or a Func eval on a block.  Square Bracket 
become the form (quote arg ...) of Scheme.

Regarding the conclusing I find this base less. There is nothing 
missing in Scheme. The first Rebol interpreter was written in Scheme. 
I already said this both languages are Turing complete so they can 
perform the same computations. As I said the topic of compilation 
vs interpretation is arid regarding PLD. But compilation vs compilation 
is important for performance considerations and for bootstrapping.

Compiling Scheme to Rebol has nothing to do with that argument. imo.

There is nothing missing in scheme, but there is something missing 
in rebol :)

Lots of parens for example. To solve such situations, rebol needs 
runtime-informations. Which function do i have here at this moment, 
with how many arguments? Without that information the meaning of 
some code is not clear, and it is only available at runtime. So early 
macros have no chance here.

Then there are dialects. They are data with rebol inside. Which parts 
of a parse-rule can be compiled to rebol? Could work if 'parse is 
a macro, up to some point.

But then there is vid. A macro would need to write a lot [ make face[] 
]. Such things grow big. And even then, look at [text a b] . At runtime 
this is easy, [a: 60x24 b: "Hello Scheme"], no problem. At macro-time 
no chance IMHO.

Scheme can be compiled to rebol, because a scheme-programmer has 
to give enough informations at compile-time. Rebol can not be compiled 
to scheme because rebol lacks that information. Making the life for 
the programmer easier, because more can be implicit.

Scheme could interpet dialects too, but then its no longer compiled. 
ANd it can not as good, because rebol-data can reference locals. 
Symbols with context. And scheme can not AFAIK, symbols are only 
unique strings. (i still hope i miss something, maybe a schemer would 
use little closures?)

(MY first counter: making to much implicit actually makes life for 
programmers harder, when he reads it. But that holds for large programms, 
and rebol is optimized for small.

the first rebol interpreter was written in C (not Scheme) by a Schemer... 
and indeed it was *not* rebol and Carl had to rewrite it from scratch. 
:)

so, if there's nothing missing in scheme, i challenge you to write 
a translator from rebol to scheme. i will do a translator from scheme 
to rebol if you want me to. this has nothing to do with being turing 
complete. brainfuck is turing complete, but don't tell me it's the 
same as scheme.

i will do a translator from scheme to rebol if you want me to.
 <--- don't you have R3 stuff to do? :-)

do you expect me to do that overnight? ;) also, i think it's very 
easy to do. (a translator does not mean that all the function are 
then available, just that you translate code, and as long as you 
define the functions in rebol, then you can evaluate it)

and anyway, i don't think jaime will ever be able to do a rebol>scheme 
so there's no problem ;)

although I'm not an expert on languages (even if I have been fiddling 
with antidote a bit) the binding of code in REBOL seems to be the 
compilation killer.  the fact that any data only gets meaning when 
a particular part of code is reached and depending on the current 
state of the whole heap, means its impossible to compile by default.

btw, trying to bring the discussion to a less tech level  ;-)  some 
people are way lost here  ;-)  I know I am just at the edge of understanding!

but wouldn't the bind command and any internal rebol binding, be 
in fact where the JIT calls are made?  aren't these explicit points 
in time where a JIT could be applied?

It is Relative Expression Based... :)  Human hinting in source code 
may alleviate some

of the late binding issues, but I'd think a REBOL compiler would 
always need access

to the interpreter at runtime (or JIT compile component like you 
said), or restrict use

of external code loaders in compiled code and a myriad of other features.

as brian said, the vast majority of rebol code can be compiled, but 
I also know that 100% of my gui using code cannot, cause of a patch 
in glayout  ;-)

things like 

insert second myfunc [print "hehe"] 

can't be compiled...

Gabriele, Just look at Sherman. A Rebol to Scheme compiler.

Written by Joe Marshall.

Maxim your code modifications to predifine mezzanies could be compiled.

Let me restate the problem with rebol and compilation is not that 
is impossible. It is just not practical without given some dynamism.

The dynamism that makes compilation hard is related to the order 
of execution of certain code.

Jaime;  I think Maxim might be pointing out that the [print "hehe"] 
may not be know.

It could be external or generated etc...  But I don't want to speak 
for Maxim, it was a
feature I was thinking about.

The majority of the code in rebol follows a straight line. But you 
can make that straight line have a twist depending on the order of 
evaluation for some expressions. Which a compiler can predict. Because 
this predictions can be broken with any function call the compiler 
must  pick one branch of the call-tree. Which may not be what the 
programmer intended.

Let me rephrase my sentence...  ;-)

can't be pre-compiled...

  only a JIT could detect that and then make a copy of the (new) compiled 
   function and start using its new pointer.

Yes. But those type of code modifications are easy to tackle by current 
compilations techniques.

it obviously depends where that code insertion is done no?  think 
about a situation where the insert is done in a button action.... 
how could the compiler understand that?

binding is done when the dialect is parsed... so only a JIT could 
detect that no?

unless they invented a new compiler called HAL  ;-)

The exponential problem of compiling a call-tree becomes impractical 
as the number of functions increases. There are some techniques to 
mitigate this, but rebol is atypical in the sense that his CFG lacks 
any punctuation. Without punctuation there is no easy way to determine 
where the expression begin or end.

true.