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

[Brian T. Rice]

At 08:20 PM 1/23/00 +0100, Massimo Dentico wrote:
>Or you read my proposal as "arrow system = language" probably because
>my capacity to express ideas in english is quite scarce.
>In this case I try to re-phrase the questions.
>
>I make these assumptions (everyone of which you could reject,
>of course):
>
>1) the arrow system is a powerful modelling framework;
>2) it's possible to model in the Arrow System (AS) a VM and/or
>   a language (VM/L);
>3) it's possible to model in the AS a VM/L especially suitable
>   to describe the arrow system itself (or the key ideas);
>4) it's possible to map this VM/L directly to the machine level;
>5) it's possible to model the machine level (or a remarkable subset)
>   in the arrow system at the end to facilitate (or even to prove
>   the accuracy of) the mapping at the point 4;
>6) it's possible to do this *practically*.
>
>So, my questions are: do you have ever considered a development of
>your system in this manner? In affirmative case, why do you have
>rejected it?

I have been trying to fit arrow *into* a VM. This is what I was working on
up until a month ago. I have since then discovered how to relate the arrow
ideas to the principles of co-induction, which are drastically different
from the principles behind formal languages (which include VMs, programming
languages, and the like). This kind of information will have to drastically
restructure the paper, but it will be worth it.

For a reasonably well-written overview of how co-inductive principles
relate to computing, see http://www.cs.brown.edu/people/pw/papers/bcj1.pdf

As for your six assumptions, I therefore disagree firmly with #3. That is,
"a VM/L specifically suited to describe the arrow system itself (or the key
ideas)" does not exist. This is not to say that formal theory as a
formalism itself can't be shifted to a co-inductive base; it certainly can,
and this would allow the kinds of things that arrow wants to do. However,
it also winds up breaking the formal language model from the start.

>Massimo Dentico

Hopefully for the last time in this thread,
	Brian

P.S. Although there's not much more to say about the HLL/LLL plan, I have
yet to see any really valid reason for a LLL if its only purpose is to
bootstrap the HLL and then be discarded. What difference would it make to
my Slate implementation if it were based on Forth (Lord help me) rather
than Smalltalk? To me, both are as equally horrendous as C, and any number
of "abstraction layers" is no worse than one elegant one if it gets the job
done. The only purpose of the HLL is to reflect on its own implementation.
Therefore, the entire argument centers around making a direct-to-hardware
compiler in the HLL, which has nothing whatsoever to do with how many
abstraction layers there are within the HLL's original implementation. In
other words, the LLL-based implementation is there to be thrown away. The
first HLL implementation within the LLL is a doomed project from the start.

I can think of a few reasons why implementing the HLL in an abstract LLL
would be beneficial to "porting" the implementation to the HLL, but I don't
see Forth helping this at all.

As far as I know, this is the only point of the entire Tunes development
architecture.