Re: Slate for Tunes HLL?

Brian,

it will be rather ironic if the Tunes HLL ends up being based on Self since I
decided to keep Merlin as a separate project because I felt Faré need something
much more Lisp-like to achieve his goals. I know you have borrowed from Lisp
(as well as Beta and Cecil) so it might turn out suitable for Tunes.

In my opinion, these two features are the same thing -

  Self: Procedures are prototypes of activation records

  Beta: Objects and functions unified as patterns

There is little difference between having the internal code representation be
abstract syntax trees or bytecodes from the viewpoint of implementing a dynamic
compiler. Source-to-source transformations, on the other hand, are much easier
with ASTs.

One thing that seems really cool about Beta initially but later turns out to be
a bad thing is:

  Patterns can form the basis for threads and co-routines

We need a much better model of concurrency than this. Wirth tried to prove that
we don't when he created the Oberon system but you just have to tried that
compared to, for example, the BeOS to see that he was very wrong.

I know that Self can be greatly improved upon (though it is already almost good
enough for what I need. Heck, even Squeak is almost good enough!) but the true
path is to take things away from it, never to make it more complex. One
example: both David Ungar and I feel that to have both method objects and block
objects in the language is too much. But neither of us found a way to simplify
this yet.

One cute language I created is called NeoLogo (it was also known as Troy) and
tries to be totally compatible with Logo while being much simpler and having
Self's semantics. There is a short description on this page:

   http://www.merlintec.com/pegasus2000/e_neologo.html

but the most interesting aspects (such as the "as" conversion operation as an
alternative to multiple inheritance) aren't there, unfortunately.

-- Jecel