Lambda (was: Refactoring in Tunes)
Brian T. Rice
Thu, 20 Jan 2000 19:25:08 -0800
Although I've been following the discussion intently, and generally staying
neutral on all sides, I have to clarify why the stance taken here on Slate
is mis-informed (mea culpa).
Massimo Dentico wrote:
>> The Bottom Line
>> The problem I foresee is that any HLL built on the LLL risks
>> destroying these properties and hence something precious. ie. I would
>> predict that for Tunes to succeed in its stated aims the HLL _will_ be
>> exactly the LLL, but with a excellent suite of library routines.
>I strongly advocate the traditional Forth approach to portability:
>a minimalistic core in assembly and/or metacompilation. I'm against
>the use of C language because usually it's hard to verify a C program
>and a C compiler (even the most simple C compiler is complicated
>compared to a Forth environment). You know it, a C compiler itself
>is often written in C and in this case the HLL interpreter/compiler
>also, so the problem is amplified.
>For the same reason I don't like the approach of Brian with Slate:
>the virtual machine (VM) used by Squeak seems too complicated. I think
>it's possible to obtain the same expressive power with a very simple VM
>(compared to Squeak VM). It's only a conjecture, of course, but I prefer
>to pursue the way of semplicity. In particular, IMHO, arrows maps quite well
>on Forth-like words: a word definition is a composition of others words as
>an arrow is a composition of others arrows (or am I wrong? I refer to
>the cited "A Crash Course in Arrow Logic"), so if "a" is the composition
>of "b" and "c", written as "Cabc", we can equivalently write ": a b c ;".
>We could impose that a colon definition (":") must obey to the same laws
>valid for the composition and make equivalent the two writings.
>Moreover we can see a colon definition as an s-expression, but without
>the explicit mention of parameters (only constants are cited).
The Slate model has nothing to do with the VM model of Squeak, or Self for
that matter. I'm simply putting together the simplest model possible for an
unrestricted extensible *inductive* type-system. The relevant idea from
Squeak is simply that their motivation and methodology with the language
libraries is something that I would like to emulate. The execution model
and semantic model are almost entirely discarded, as you'll notice if you
follow the slate docs page at all.
It's also nice to know someone's considering the semantic modelling
capabilities of arrows to some extent. :)
Sorry that I had to point that out.