Hi, Andrew!
[EMAIL PROTECTED] wrote:
>
> > 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.
>
I'm sorry, but I must disagree. The JVM and its bytecode were specifically
designed for the Java language; many of their features are directly related
to requirements, features, and concepts of the Java language. By the same
token, concepts NOT part of the Java world-view would be VERY difficult to
map directly to JVM bytecode. The "mere" mapping of REBOL functions to
JVM bytecode is not very "mere" where REBOL has a concept missing from
Java.
Let me give just a couple of brief examples:
1) Java uses a class-model style of OO programming, in which one defines
a "class" (at compile time) as a kind of factory or classification
entity, then creates objects (at run time) by asking the class to construct
an "instance" of itself. REBOL uses neither the class/instance distinction
nor the compile-time/run-time distinction.
2) Java draws a sharp distinction between code and data. REBOL, as a pure
von Neumann language, refuses to recognize that distinction. It is
trivial to write REBOL code that modifies itself, or that creates a new
function (or just a block) at run-time, and subsequently evaluates/executes
that newly constructed expression. I know of no reasonable mechanism in the
JVM that allows running JVM bytecodes to manufacture new content for the
runtime constant pool (which is where symbolic references to classes,
methods, method signatures, etc. are stored).
An example of an unreasonable mechanism would be for the running code to
compose an entirely new class file on the fly, then invoke the class loader
on that new class file. I believe the overhead of such an approach would
be intolerably high for any practical uses.
3) Java is a strongly-typed language. JVM bytecodes for such common actions
as comparing two values depend on advance (i.e., compile-time) knowledge
of the types of the values being compared. Different opcodes are used for
comparing two integers than for comparing two doubles, for example. Also,
invoking a Java method (e.g., via the INVOKEVIRTUAL opcode) requires a
reference to the constant pool which provides a method signature (which
includes identification of the types of all arguments). REBOL, by contrast,
can punt on the entire issue of function argument types, leaving that issue
to be handled implicitly by each operator or explicitly by the high-level
code.
Based on the above (among other issues), the REBOL code:
block1: [a: 1 b: does [print a] z: func [x] [a < x]]
block2: [a: 2.3 c: does [print ["fee has" a]]]
foo: make object! block1
fee: make foo block2
fum: make object! append copy block1 [
z: func [x] [either number? x [a > x] [false]]
]
poses a number of significant challenges to any attempt to render it into
equivalent JVM bytecode.
>
> 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.
>
I don't understand this sentence at all.
Bytecodes typically deal with more fine-grained, operationally oriented
concepts than high-level programming languages. The translation process
is only "a simpler conversion" (than compilation to object code for some
physical computer?) if the defining concepts of the source language and
the byte code are nicely aligned.
>
> 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...)
>
Different concepts.
>
> By an interpreter I take it you mean parsing REBOL code and mapping
> REBOL commands to JAVA commands and executing them?
>
No. The distinction I'm drawing is between
a) Writing a compiler (in whatever lanaguage -- that's irrelevant)
that reads REBOL source code and produces standard Java class files
which can be executed using a standard JVM. That's I was discussing
in the first section above.
b) Writing a REBOL intepreter IN Java -- i.e., a Java program that
reads REBOL source code, parses and analyzes it, and then performs
the actions specified by that REBOL code.
Those are VERY different. And, IMHO, the first would be extremely
difficult (if not totally infeasible), while the second would likely
be too slow for any realistic use.
-jn-
--
; Joel Neely [EMAIL PROTECTED] 901-263-4460 38017/HKA/9677
REBOL [] print to-string debase/64 decompress #{
789C0BCE0BAB4A7176CA48CAB53448740FABF474F3720BCC
B6F4F574CFC888342AC949CE74B50500E1710C0C24000000}
