[self-interest] juice (was: The Effort on Self)

[Jecel Assumpcao Jr]

Jay Osako wrote:
> 1) The parse tree is usually more compact than the bytecode equivalent.

I really doubt this.

> 2) It is language independent (sort of).

In the Oberon list, there is a guy who wants to translate C into
Oberon. Several people pointed out problems, but nobody mentioned
*the* killer problem: C has pointer math and Oberon does not (and
so neither does Juice, which is the slim binaries you were talking
about). For those interested in looking into this:

    http://caesar.ics.uci.edu/juice/

> 3) It allows greater optimization, as all of the high-level structure
> is
> accessible to the code generator.

It is true that you won't be doing things like constant folding
from a bytecode representation. But these things were probably
done by the parser before generating the bytecodes.

On the other hand, at least the first Self compiler would read
in the bytecodes and then generate something like a parse tree
to do type analysis. In that case it would make sense to just
save the parse tree directly.

BTW, the Beta people just love to work with AST (Abstract Syntax
Trees) and Ole Madsen included several tools for working with them
in Self 4.

> 4) All validation can be performed during the initial compilation,
> making the Just-In-Time part faster.

Why can't the exact same validation be made when generating the
bytecodes?

> 5) It would still leave the possibility of a JVM implementation; in
> fact, it would be considerably easier, as much of the work of compiling
> is aleady done.

I don't see the difference.

> 6) It would make rewriting the entire Self environment in Self a
> practical option, provided there was an existing code generator on the
> initial development platform.

Once again, it seems to be that bytecodes and Juice style binaries
are equal in this regard.

Please note that I am not against using ASTs to represent code. See
my 1984 Smalltalk design for an example:

  http://www.lsi.usp.br/~jecel/st84.txt

But I have come to the conclusion that bytecodes are equivalent
and more compact, so now I prefer them. As long as there are few
of them: 8 whole bytecodes is more than I can remember at once ;-)

-- Jecel