Slate for Tunes HLL? (was: Lambda (was: Refactoring in Tunes))

[Brian T. Rice]

At 10:12 PM 1/21/00 +0100, Massimo Dentico wrote:
>"Brian T. Rice" in the thread "Re: Lambda (was: Refactoring in Tunes)"
>also wrote:
>> 
>> 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.
>
>I'm completely lost here: do you intend to use Squeak for bootstrapping
>your arrow system, yes or no? I have understood that you have this
>intention from your messages on this mailing-list. What about your
>arrow prototype in Smalltalk (Squeak)? You have even talked about
>a Lisp interpreter for Squeak and you write about Lisp code here:

The arrow system is absolutely not a language, it's something else. One way
I've recently found to describe it is as a language-independent
co-inductive type system. In that sense, I'm rejecting Squeak in favor of
Slate, mostly because of language issues.

I should also mention that one reason for using Squeak is that it has
useful tools for generating parsers, and it is relatively simple to create
a compiler from Squeak VM sources in the smalltalk language and the
C-Translation library. 

I guess I should make it clear that I don't appreciate the HLL/LLL model at
all. As I understand it, this involves using the LLL as an extension
language as well as a close-to-the-hardware implementation hack that
doesn't resort to unsafe assembly or c. This is totally not what using
Squeak is about. The only thing I want is to implement Slate over a
relatively abstract language, so that the source code exposes the semantics
in simple terms. Otherwise, I will make no use of the implementation
system. The same goes for the common lisp code currently being used.

At any rate, I can see that it's pointless to continue debating this. I
will implement Slate in one way or another, and you will either accept it
or reject it. That's all there is to it. The HLL/LLL issue is a non-issue.

>So ".. Slate is a testbed for some Arrow ideas ..", but I don't understand
>what this means. Slate is only a preparatory work? Why this effort?
>See later ...
> 
>> It's also nice to know someone's considering the semantic modelling
>> capabilities of arrows to some extent. :)
>
>I want to emphasize: *some* extent. The Forth example is exactly this:
>only an example! The underlying idea is: why not map *directly*
>(1:1 or near 1:1) the arrow abstraction to machine level?
>I have suggested the connection with Forth because is well-known
>that is possible to map Forth directly to machine level, with less
>possible layers of abstractions (this is the motivation for which
>Moore has invented Forth). What are the difficulties of this operation?
>
>Because if you are not following this way evidently you think there are
>some insurmountable difficulties. Why, on the contrary, do you think
>that is necessary to interpose several layers of abstractions to
>implement ".. some Arrow ideas .."? Arrows have certainly a powerful
>semantic modelling capabilities but are even incredibly *simple*
>(as I understand arrows).
>
>Probably I miss something. Where am I wrong?

Yes, you're missing everything that I've written about arrows, which
encompasses a much greater scope than "arrow logic". This entire
development is not about layering abstractions, in the sense of
implementation. That arrow logic paper covers maybe 1% of my ideas for
arrows, so don't identify my opinion with it's formalism. If you really
want to ask questions about Arrow, quote the paper or something.

>-- 
>Massimo Dentico

	Brian