Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Compiler for Rebol ? Re:(13)

From: joel:neely:fedex at: 27-Sep-2000 16:58

Hi, Andrew! [handy--techie--com] 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 [joel--neely--fedex--com] 901-263-4460 38017/HKA/9677 REBOL [] print to-string debase/64 decompress #{ 789C0BCE0BAB4A7176CA48CAB53448740FABF474F3720BCC B6F4F574CFC888342AC949CE74B50500E1710C0C24000000}