Slate for Tunes HLL?

[Brian T. Rice]

At 07:49 PM 1/20/00 -0200, Jecel Assumpcao Jr. wrote:
>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

Well, right now I am considering implementing implicit object state for the
purpose of functional semantics orthogonal to traditional object state
ideas, so it's a little variation on the generic self idea where all state
is equal in semantics.

If you want a different (perhaps more accurate) take on Slate, you could
simply consider it a particular MOP for a Lisp object system considered as
a language of its own.

Here's a preliminary (pseudo-random) plug for a Mobius feature under
consideration: we're re-introducing the notion of "class" into the Slate
language using the notion of a co-inductive type system. I'll explain the
details soon.

>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.

Yes, source-to-source translation is exactly what I am considering, and
there's also the possible extension to full graphs vice trees. However,
graphs should probably be a non-standard feature for later on, rather than
"core" semantics.

>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.

That's an excellent point that I'm working on addressing. Primarily, I want
to integrate a clean generic semantics that includes pre-emption into the
idea of the 'object as thread' model. This seems to me to involve an
orthogonal relationship of the language to the distribution semantics of a
computation. I know that there's a paper showing how to express concurrency
semantics using rewrite logic in Maude, but I don't recall if it
encompasses pre-emption ideas. I'll look again to see what it would take to
express these things well.

>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.

Yes, I'm looking at this currently as well. Most of the arguments revolve
around the treatment of symbols and block-closure. So far, we're not
supporting block-closure in the usual sense, but I haven't worked out all
of the details 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

That reminds me of the toy language that I wrote in college after reading
about Self and Tunes and Merlin. It was just a lisp-style object system
with a visual self-hosted interface. It's also the basis for some of my
Slate ideas.

	Brian