> No flaming from me; just puzzled head-scratching. It's not clear to me
> that REBOL and Java are conceptually close enough to be ABLE to compile
> REBOL directly into Java bytecode.
Im taking a guess here, but it seems you are thinking at a much higher level
than I am.
Theoretically conversion from REBOL to bytecode doesnt require any
syntactic/semantic resemblance to Java, merely a mapping of REBOL functions
to bytecode sequences.
Further, this conversion would be somewhat simplified by the fact that the
bytecodes are
much more finite than the language that it is compiled from (an analogy:
c -> RISC assembler),
creating less mapping possibilities, making it a simpler conversion process.
Im afraid that I am new to both languages and cant adequately go into detail
on the points you raised...BUT:
> It would certainly be possible to create a REBOL interpreter written
> in Java, but that's not what I understood you to be suggesting (and
> my experience with Java suggests that it would run like a pig on
> tranquilizers...)
This process would entail roughly the steps I am talking about! ...albiet at
the language level, not the bytecode level (but you can always go from
lang->bytecode so...) By an interpreter I take it you mean parsing REBOL
code and mapping REBOL commands to JAVA commands and executing them?
Does this not represent a roughly adequate conversion process? That is,
store the commands as opposed to executing them (and maintain a variable's
dynamic nature), and then compile the resulting source (it would be shocking
source - probably all linear)? Then were home & hosed ... compile to
bytecode and to native machine code (if need be - yes i am aware of the
design violations this incurrs but ... :)
Although I do admit it would be extremely hard to achieve dynamic generation
and resultant execution of code ... eg #1 on your list ... hmmm :)
AndrewH
