HLL and misa...

[Jecel Mattos de Assumpcao Jr.]

Let me make a few comments on this very interesting thread ( BTW - is
Garth on the Tunes list? I like to avoid sending multiple copies of
a message to the same person )

> >    I hope that you won't disappoint them. I wish I can help !
> 
> you can.  you all seem like an intelligent group of people and i hope
> to bounce some of the latest of our research with you.  any comments
> our suggestions are very welcome.

I would suggest you stick around this list - I am working on my own
system rather than Tunes but have gained a lot with these discussions.

> i can tell you right now - you're not going to find a language which
> meets the requirements of your HLL.  we have spent enormous amounts of
> time scouring the net for a language which provides what misa will
> provide (which is more or less what you require for you HLL).

I would be very interested in seeing a list of what you looked at.
Here are some languages I studied for my Merlin project:

  Self, Smalltalk, Prolog, FP, Sisal, Moostrap, TSOL, C, Objective-C,
  Forth, LISP, NewtonScript, Echonet, APL, Actor for Windows, Act-1,
  Occam, Oberon, Logo, Hypertalk

Here are some languages I looked at but would like to know more about:

  Dylan, Java, Icon, Agora

Languages I wish I knew:

  Beta, SML, Haskell, Perl

If I thought about it a little more I might remember some others...
I think that Moostrap would help you a lot - it is a Scheme-like
language with Self-like object semantics and a very good reflective
structure.

"Definition of a Reflective Kernel for a Prototype-Based Language"
Phillipe Mulet and Pierre Cointe
International Symposium on Object Technologies for Advanced Software
ISOTAS'93

Sorry - I lost the ftp address of this paper, but can look it up if
there is interest.

> perhaps even if this language turns out to be what you are interested
> in, you could use it for the basis of your HLL. 

I say that the less language there are in the world, the better!

> i would, however, be very interested in getting more people involved
> with the definition of this language.  you and anybody else is
> welcome.  

I like to hear other peoples opinions, even if I end up ignoring
them in the end :-) It is much nicer to make a choice because you
decided it was the best way and not because you hadn't heard of
the alternatives.

> my point was that on the abtract level s-exp are very useful.  never
> mind the fact taht it's in a linked-list which has cars and cdrs and
> all that nonsense.

An alternative is to use arrays ( or vectors ) like Smalltalk-72 did.
So "((x b c d) x 9 (z z))" would be translated into 3 arrays rather
than 10 cons cells:

         ---------------------------
         |      |      |     |     |------
         ---------------------------                /         \_______\=--------              /                     \      \       ----------------------------   x     9    ----------------
  |      |      |      |     |              |       |      |
  ----------------------------              ----------------
    |       |      |      |                     \      | 
    |       |      |      |                      \     | 
    x       b      c      d                       ---- z

( I would rather have done this in postscript ;-)

The main advantage of the cons implementation is that you can
go all over the structure just by bumping a pointer, while here
you have to combine pointer chasing *and* indexing. If the
structure is mostly static, as code usually is, there is a closer
correspondence between the source and low level implementation
with arrays than with cons cells.

> it is the _defined_, _simple_, structure that makes LISP so powerful.
> the C syntax is much to complex to achieve the runtime modification
> which is possible in LISP (not to mention all of the other things
> which make it a static language istead of a dynamic one).

C is a static language. It syntax is the least of its differences
with Lisp ( compare the old and new Dylan syntaxes and their effect
of the language, for example ).

> what we need is a defined (and, of course, redefinable) simple syntax
> which is easily modifiable during runtime.  s-exp is one of the best
> currently available syntaxes.  

I agree - you can build other, more readable, syntaxes on top of
it if you want - see Logo.

-- Jecel