[self-interest] Re: The Effort on Self

[Gordon Cichon]

Well, simply regard bytecodes as a compressed representation
of a syntax tree, and there you have it.

Nevertheless, I think you made a valid point in the sense
that for experimenting with the language features it would
be more appropriate to have a say "expanded" representation
which can be changed more handily.

In some sense, I think if we had a well done SIC written in 
Self and operating on an abstract syntax tree, and this
Compiler would compile itself, it should end up representing
this thing as bytecodes internally. (David, how do you like
this idea? Jecel, how do you?)

Gordon.

PS: BTW, what does "OTOH" and "AFAICT" mean? 

On Thu, 18 Nov 1999, Jay Osako wrote:
> gordon cichon <gordo- at cichon.de> wrote: 
> original article:http://www.egroups.com/group/self-interest/?start=435
> > On Thu, 18 Nov 1999, [ISO-8859-1] José Baltasar García
> Perez-Schofield wrote:
> > 
> > > 	In my opinion, a minoritary language like Self should be developed
> > > in a platform like Java VM. I am not a Java fan, but it provides a
> virtual
> > > machine in a variety of platforms, and also a "standard" graphical
> > > environment. This would allow to get Self expansioned, I think.
> > > 	Maybe, this is a bad idea because it would run too slowly, and
> > > would become unusable (UI is now pretty slow, even in a UltraSparc).
> > 
> > BTW, we once conducted a poll about what platform is the most
> important
> > to have Self running on. I can't recall the results right now, I
> > think Windows and Linux have been rated most important, and Java
> > was third place. (Please correct me if I'm wrong).
> 
> Has anyone suggested anything similar to the Slim Binaries used in
> Oberon? These are, essentially, an intermediate parse tree, which can
> be passed between platforms until actually used, at which point a code
> generator builds the actual application in native code (much like the
> JIT, but without the bytecode layer; it would cache this generated code
> for future use). This has a number of advantages:
> 
> 1) The parse tree is usually more compact than the bytecode equivalent.
> 2) It is language independent (sort of).
> 3) It allows greater optimization, as all of the high-level structure
> is 
> accessible to the code generator.
> 4) All validation can be performed during the initial compilation,
> making the Just-In-Time part faster.
> 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.
> 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.
> 
> OTOH, SB itself is not an 'open' technology, so we would probably have
> to create our own equivalent (its copyrighted, but I don't think it is
> patented, I'd have to check). Also, the claim that it is language
> independent is rather questionable, at least in the existing system;
> like the JVM, it is definitely targetted towards imperative/OO hybrid
> languages, AFAICT.
> 
> Any comments?