HLL and LLL, Scheme and Forth (long)

Thanks Jecel for your insight.

> === LAYERS IN MERLIN ===
   I admit a layered approach is cleaner,
and should be the way whenever there is a clear idea of where to go.

> === SPIRAL MODEL ===
   It seems that the exploratory nature of the HLL
(that should be based on dynamic reflection, free annotation, and migration)
makes a clearly layered model unlikely.
   So yes, the spiral model you describe is somehow what I always thought
(but not what I always worked for ;-( ) the Tunes project should be,
and it's better off now that you cristallized this idea by your fine
message.
   Surely I got mistaken in trying to build the Tunes code from ground up
with this silly assembler+macroprocessor stuff.


> === SCHEME ===
> One implementation of Scheme that looks interesting is RScheme:
   Will have a look.

> I don't know what the various object models for Scheme are, but
> I feel that adding objects should simplify the language, not
> complicate it.
   I fully agree.

> A good object model might be based on the fact
> that closures and objects are so similar, for example.
   The problem with this approach is that there is no standard
way to join, split, or resolve closures, so an object model
built on closures could only be the fully dynamically resolved
single-inheritance model (or maybe I'm missing something).


> === HLL ===

> We can devide
> languages into two groups (says Alan Kay):
> 
>   - agglutination of features (COBOL, PL/1, Ada...)
>   - crystalization of style (LISP, APL, Forth, Self...)
>[...]
   That's a very good description of languages;

   As long as the Tunes HLL will be exploratory,
it will most certainly have to be of the first kind.
But at the same time, I hope exploration shows us
a core of language constructors and meta-constructors
that are enough for the language to be built upon;
however, I'm sure that whatever core we find, it will
be incomplete in that it allows specialization toward
opposite programming paradigms.
   For instance, the Tunes HLL should be able to manipulate (e.g.)
pure functional programming style (with possible linear variables)
as well as side-effective imperative style. While either paradigm
given some basic constructors is expressive enough for Turing-equivalent
computing, these are incompatible at base level (that is, there is no
local transformation of programs from one paradigm to the other);
reflection allows one to be expressed in terms of the other, by keeping
track of a globally defined context.
   I want not to priviledge or reject any programming style
without universally valid reasons.
Thus, it seems that Tunes will have not a core of constructors
that cristallize a style, but will rather have a collection/library of
objects and meta-objects that can be assembled in many ways.
   Such constructors should include some kind of typed lambda-expressions,
tagged structures, memory managers, various type system and
evaluator components.

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"