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

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

From: joel:neely:fedex at: 1-Oct-2000 21:45

[chris--double--tab--co--nz] wrote:
> > 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. > > Have you seen Kawa? The scheme compiler that compiles to JVM and > executes the byte code on the fly [1]. >
Not before your post. Thanks! I've been looking at their site since receiving the URL you provided. I'm quite impressed with what they've done.
> It would seem to face the same sorts of problems as a REBOL-on-JVM > would face and it works quite nicely. >
I guess it depends on one's definition of "quite nicely". My own definition of "nicely-working" REBOL-on-JVM is quite simple (and quite strict!): it must be totally equivalent in functionality to REBOL as supplied by RT. One should be able to pick up any working REBOL script and compile/execute it in the alternate environment with no changes and no feature unsupported. Bear in mind that there are already many versions of LISP/Scheme. I suspect that the shock to the LISP/Scheme community of stepping from N version to N+1 versions would be smaller than the shock to the REBOL community of stepping from 1 version to 2. Further, there is already a large body of literature using the Scheme language (including the seminal SICP). Having more options for running programs in a widely-publicized language is a good thing, but that's not the most burning issue for REBOL, IMHO. In addition, I view Scheme as a significantly simpler language than REBOL. I should also add at this point that the "internals" of Scheme are FAR better documented than what is currently available for REBOL -- regardless of whether this is because of RT policy, trade secrets, work-in-progress issues, or just the fact that Carl and the other folks at RT deserve at least three or four hours of sleep a week! ;-) Finally, I'm not challenging the theoretical posibility of doing REBOL on a JVM, but I have serious questions about how practical it would be, depending on one's objectives.
> [1] >
Having looked briefly through that site, I am impressed by the work that's been done thus far, but it appears to fall short of the (admittedly hard-nosed) criterion I stated above. Consider the partial list of exceptions and caveats quoted from the site above: Also, call-with-current-continuation is only "upwards" (?). I.e. once a continuation has been exited, it cannot be invoked. These restricted continuations can be used to implement catch/throw (such as the examples in R4RS), but not co-routines or backtracking. Here, a feature of the language can't be used in Kawa to do some things it can do in standard Scheme. Kawa now does general tail-call elimination, but only if you use the flag --full-tail-calls. (Currently, the eval function itself is not fully tail-recursive, in violation of R5RS.) The --full-tail-calls flag is not on by default, partly because it is noticably slower (though I have not measured how much), and partly I think it is more useful for Kawa to be compilatible with standard Java calling conventions and tools... I assume that "compatible" was meant by the mangled word in the next- to-last line; if so, compatibility with Jave was deemed useful enough to influence the default behavior of this implementation. Even without --full-tail-calls, if the compiler can prove that the procedure being called is the current function, then the tail call will be replaced by a jump. This means the procedure must be defined using a letrec, not a define (because the compiler does not know if someone might re-define a global definition), and there must be no assignments (using set!) to the procedure binding. Note the parenthesized remark that "the compiler does not know if someone might re-define a global definition", a perfectly reasonable thing to do in REBOL. If you define a macro with defmacro, you (currently) cannot use the macro in the same compilation as the definition. A fairly severe restriction, IMHO. The current Kawa compiler is rather simple-minded, and in many places only allows simple types that the compiler can evaluate at compile-time. More specifically, it only allows simple type names that map to primitive Java types or java classes. Another example of a Java-oriented language compromise. This next one needs some explanation. The rules for valid names in Scheme are different (and much more liberal) than the rules for valid names in Java. Kawa "mangles" (their word, not mine) Scheme names into the more limited options allowed by Java. With that background: Note that this mapping may map different Scheme names to the same Java name. For example `string?', `String?', `is-string', `is-String', and `isString' are all mapped to the same Java identifier `isString'. Code that uses such "Java-clashing" names is not supported. In other words, you must know what names are legal in Java and how Kawa maps Scheme names to that more restricted set, or risk having multiple names that end up the same. If so, tough luck. The behavior of interpreted code and compiled code is not indentical, though you should get the same result either way unless you have designed the classes rather strangely. In contrast to the previous point, no explanation for "rather strangely" is given. Thus, there's no guarantee that you won't write "strange" code which behaves inconsistently. Let me be VERY clear. I'm impressed with what the Kawa team has done, and do not intend my comments to reflect negatively on their accomplishments. What I am trying to point out, however, is that a quick perusal of their web site reveals that using Kawa is not SIMPLY a matter of taking any working Scheme program and dropping it into their compiler. Even if it were feasible to build a REBOL-onto-JVM compiler of comparable quality to Kawa, I wonder whether the brainpower might be more profitably spent on other REBOL promotion and support issues: documentation, more tutorials, building a "standard library" of widely-needed and reusable objects/functions, etc. Thanks for the very interesting link! I'll plan to read more on what they're doing with Kawa. -jn-