Maybe later we can have a Bazaar..

[Fare Rideau]

>: Tril

> 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
>
Good. Consider yourself in charge!
I'll send you diffs relative to 0.0.0.34;
I'll also open an account for you on machine that www.tunes.org
will point to, so you can setup everything.


[About the LLL]

> I would hardly call the LLL "overhead".
Well, perhaps I should have written that the choice of a LLL would
have trade-offs, sacrificing some hardware adequacy for portability.
The goal in mind would then be to save overall development time,
not to optimize the implementation on a particular hardware setting.
No extraordinary discovery, but worth mentioning.

> 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.
>
Yup. I have presented things on the LLL page from an erroneous point of view.

> 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.
>
100% agreed.

> Why develop LLL as a static entity, if it will only be subsumed?
>
Well, we can develop it as a dynamic entity;
still we need an initial state, and it will have a state, at any moment
(even though that state gets less and less identifiable as the system
develops and distributes).

> 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.
>
That's a valid point of view.

> 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.
>
> 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?
>
Why not, indeed? Well, that might be a good place to start.
However, it's trickier to do than to say.
For instance, how would user-specified typing go into the whole thing?
Lisp dialects (Scheme, ISOlisp, EuLisp, CommonLisp; even Dylan)
tend to avoid that having trivial typing.
ML dialects (SML, OCaml) tend to have underexpressive typesystems.
Other languages have interesting features of reflection (BETA, CRML),
or linear logic (Clean), or non-determinism (Mercury), or real-time, etc.
Writing a system that could unify all these paradigms is a challenge
[See following message].

> 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.
>
Well, bootstrapping is always incremental, but I guess you call for
a coarse granularity in the process. Well, it has been done in the past,
so why not? As usual, I'm unhappily not the one who can support or
contradict such a claim.

PS:
* I fully agree with your 19971206 message <<Re: A "few" questions about
 Tunes>> where you describe the Tunes idea for a programming interface.
* however, I slightly disagree in your 19971207 message <<Re: Just some
 initial thoughts>>, when you say that writing Tunes from the bottom up
 would be disastrous. Surely in the long run, low-level hacks should be
 replaced by fully specified high-level meta-programs; however, I feel
 they are just necessary in the beginning, and can't do harm, if they are
 known to be transient, and not THE standard. Anyway, see my usual disclaimer.

== Faré -=- (FR) François-René Rideau -=- (VN) Уng-Vû Bân -=- rideau@ens.fr ==
Join a project for a free reflective computing system! | 6 rue Augustin Thierry
TUNES is a Useful, Not Expedient System.               | 75019 PARIS     FRANCE
http://www.eleves.ens.fr:8080/home/rideau/Tunes/ -=- Reflection&Cybernethics ==