Re: Slate for Tunes HLL? (was: Lambda (was: RefactoringinTunes))

"Brian T. Rice" wrote:
> 
> 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.

Thanks for the replay. *Now* it's enough clear, for me, the evolution
of your ideas: you have riched a "condition" (if not a proof) of non
existence. However, the paper is the same that I have cited some time
ago on this mailing-list.
 
> Hopefully for the last time in this thread,
>         Brian

It's difficult to end a thread when in a post scrittum you ignore,
misunderstand or distort what I have written (as I have often admitted,
in a horrible english); but I agree with you, it's time to stop here
this discussion.

However, I confirm my interest in your work on arrow system
and now Slate, even if I disagree with some implementation choices.
 
> 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.

-- 
Massimo Dentico