A plan for implementing TUNES

[Massimo Dentico]

> It doesn't seem as much as a layered architecture,
> as it is a breakdown into logical constituent components.

Sorry, wrong quotation from my part, I was in a hurry.

It is not clear to me how he intends to "layer" (implement?)
Arrow on top of Epigram on top of Pliant on top of Figure
on top of an amalgamation of Mozart/Oz, E and Erlang
on top of Factor nor what advantages can bring to us.

I have only asked a *specific* question and, if possible,
a very brief explaination, otherwise pointing to documents
on his web site can do. If he has a convincing plan I could
even decide to help him.

He stated: "honestly, I will work on it whether you want
to cooperate or not", so what's your concern?


> Makes the concept as a whole more digestable (less complex),
> and allows work to be started, instead of discussing another
> 8 years.

Yes, a simple list of 7 points is more digestible than
a web site with motivations for the project:

    Why a New OS?
    http://tunes.org/papers/WhyNewOS/

and (very high-level, for the most part, but see the
HLL subproject) specifications for various subprojects:

    The TUNES Subproject Tree
    http://tunes.org/subprojects.html

But he is not so naïve to think that a short description
suffice for such a project, in fact see his web site.

This is not a project for "code monkeys" that haphazardly
write tons of code with much leap of faith and little
thought about what they are doing and why.

Discussions about design are fruitless, for the most part,
WHEN no agreement follow, certainly NOT because design is
inherently wrong (on the contrary: lack of design, implicit
or explicit, produce crap).

IMHO the number 1 problem of this project (TUNES) is
agreement on details. Someone on this list has
suggestions on how to overcome this stumbling block?
Decision procedures detailed in

    The Tunes Charter
    http://tunes.org/legalese/Charter.html

were never implemented, to my knowledge.

Regards.

--
Massimo Dentico