[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] http://www.gnu.org/software/kawa/kawa.html
>
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-
