[self-interest] Re: The Effort on Self

[David Ungar]

Great idea, Gordon!

- Dave



At 9:13 AM +0100 11/19/99, Gordon Cichon wrote:
>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?
>
>
>
>------------------------------------------------------------------------
>Need a cure for the used car blues? iMotors pre-owned cars
>are: priced below Blue Book; fully tested & certified; &
>carry a 7 day/700 mile money back guarantee. Look no further
>iMotors.com is here! http://clickhere.egroups.com/click/1535
>
>
>
>
>
>
>
>
>
>
>-- Easily schedule meetings and events using the group calendar!
>-- http://www.egroups.com/cal?listname



     David Ungar
     Sun Microsystems Laboratories
     (650) 336-2618