Maybe later we can have a Bazaar..

[David E. Manifold]

On Wed, 26 Nov 1997, Fare Rideau wrote:

> 
> The Bazaar style of development would require that we release often.
> But release what? We don't have anything particular to release;
> we don't even have a clear design. It's in most part my fault.
> Would someone maintain a list of tasks that can be done for Tunes *now*?

I don't care whether it's a Bazaar style or some other style; this project
needs to get moving regardless of style.  Here are some things I think
should be done (and since I consider these things important, I will
volunteer to maintain them):

-Rewrite WWW pages in laymen's terms
-write formal definition for HLL


Also, on another topic, the LLL.  I would research this more if the list
archive were available, but perhaps it wouldn't hurt to go over this
anyway.  Here's a quote from the LLL page:

>The LLL is not a back-end to the HLL, but a low-level core for its
>implementation. Why a LLL, some ask ? 
>     Well, firstly, the LLL is meant as a somehow portable way of
>implementing Tunes. It is a purely internal language, that shouldn't make
>it to most users, may disappear or change drastically at any new major
>release, and intended to make implementation on many platforms as easy as
>possible. Somehow, the LLL project is the basis of any implementation of
>Tunes. Why put yet another intermediate between the human and actual
>computations ? 
>     Sure the LLL is another artificial layer of computerware, that
>brings it amount of computing overhead. The hope is to minimize not
>runtime overhead (though we hope not to make it too large), or even
>compile-time overhead, but development-time overhead. Once Tunes runs, it
>is still time to focus on compile-time and run-time speed. Moreover, "the
>LLL" is not to understand as an identical abstract language on all
>machines (even C has different sizes and pointers according to the
>hardware), but as a general implementation model, that differs according
>to the hardware. 

I would hardly call the LLL "overhead".  If the LLL is the implementation
technique for mapping HLL objects to machine-specific representation, it
is absolutely required, since its purpose is to allow Tunes to exist on
a system.  Without a system for mapping Tunes to a machine, Tunes would
not be a computer system, but an abstract concept.

The LLL will be completely representable within the HLL.  This is by means
of the expressibility of the HLL, and this is also an example of the
HLL's reflectivity. 

The Tunes system will be completely reflective, that is, implemented
within itself (or this is one aspect of its reflectivity).  By exercise of
the property of dynamic compilation, which says "Information is
automatically translated into the form necessary for its utility," (from
my Tunes in a Nutshell) each part of the Tunes system will be
automatically translated into the necessary low-level representation.  All
that is required for this is the appropriate high-level objects describing
the translation.

As you said, the LLL is internal, and dynamic (may change at any time). 
In fact, the specific low-level representation of ANY object is internal
(hidden), and may change at any time.  As required by the property of
genericity, every object must be allowed to have its OWN low-level
representation that may change independently of any other object.  If the
entity we call the LLL is thus distributed, and infinitely variable, it
might be said that no identifiable, coherent, or unique LLL exists at all.

Why develop LLL as a static entity, if it will only be subsumed?

I offer another choice: Develop the HLL first.  Then design (in the HLL)
the mapping system for high-level objects to low-level implementation.
When the HLL is bootstrapped (by a method yet to be decided), it will
automatically generate its own low-level representation.

My intuition is against designing the HLL as we go, layering it gradually
on top of successive implementations of Scheme with added persistence,
modularity, etc.  I am for a complete specification of the HLL first.
When that exists, I believe an implementation will become apparent.

Perhaps my hunch comes from not knowing Scheme.  But in any case, can't we
take the formal semantics for Scheme, add our own to produce the formal
semantics for Tunes (HLL), and then implement Tunes from the bottom up,
reading from our complete specifications?  Not only do I not know Scheme,
and would not be able to help, but I think that the incremental
bootstrapping process is slow; wouldn't it be faster to boostrap the
entire system all at once?  I know it sounds drastic, but from the bits
and pieces I have gathered I think I have the crazy idea that it can be
done.

David Manifold
dem@pacificrim.net