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

[Massimo Dentico]

"Brian T. Rice" wrote:
> 
> Hello again, Tunesers.
> This is a general survey of members' opinions and such concerning the close
> relationship between the Slate design and the HLL 'specification'.
> Basically, I propose that the basic Slate concepts form HLL-, and that the
> Mobius reflection system would provide all the meta-object system that
> Tunes specifies (or doesn't). The documents are available from this URL:
> 
> http://www.tunes.org/~water/slate-home.html
> 
> for now. Potentially, this could be moved under the HLL subproject, given
> Tunes group agreement. Most of the pages are fairly ad-hoc, but gradualy I
> am systematizing the documentation and specifications.

"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:

> A lot of work has yet to be realized in the Lisp code, but then a lot
> of ideas have not been clearly enough resolved. However, I will stop
> at nothing to make it work, even if it means dropping some cool features
> in exchange for waiting for the MOP system to be operational (and get
> the features later :).
> 
> Anyway, I just wanted to gauge Tunesers' opinions on whether this could
> eventually be moved under Tunes HLL or should stay separate, with Tunes
> developing a similar language alongside it. Keep in mind that Slate is a
> testbed for some Arrow ideas, and of course I'd like to have a system like
> this to work with anyway.

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?

-- 
Massimo Dentico