high level language design

[Francois-Rene Rideau]

>>This might be the problem with us all,
>>as the project strives to not follow tradition
>>when it fails to provide clean and clear concepts.
> 
> It might help your developement if you make a glossary of terms
> or concepts so that everyone starts with the same ideas..
>
Sure. Please review the current glossary,
and contribute to make it better:
	http://www.eleves.ens.fr:8080/home/rideau/Tunes/Glossary.html

>>I don't like systems built in layers.
>>I want a unified language frame, not three independent languages.
>
> I understand that entirely, but simply because there are three languages
> does not imply lack of unification, by providing features in layers
> one gets more bite sized design chunks and each new layer simly gets a window
> into the layer below so that when required the developer can slip down to
> more precise code to write more optimal routines.  ( for security purposes
> though the lowest language is be restricted to trusted objects only. )
>
> The complexity in developing this kind of system is mind boggling, not only
> are we talking about a new paradygm, but a new structure, both of which are
> against the grain of current technology.
>
> Another reason for the layered effect is that the lowest layer provides an
> interface to current technology, this is critical if the system is to define
> itself.  This is a key problem in trying to develope a single language, in order
> to get the features required the definition becomes recursive, calling a
> behaviour in order to call a behaviour, or creating a message to create a
> message.
>
Surely, a founded implementation should have some kind of layering,
and that's how I see it too,
now that you've made it clear how your layers are related.
What I meant is that no layering
should be part of any formal interchange standard.
Two complementary points of view: specification vs implementation...

> I am very close to having a first go at a system that demonstrates this.
> it is written in perl so performance has not been an issue, and will be just
> over 2000 lines long when i finish it.  I hoe to be done and confident that
> it works by the new year.
Great! Please publish it on the Tunes repository
(contact dem or me for that) and warn the mailing list
when you have something, even if not perfect!

> ( i have not yet looked at Clean )
> it would seam to me that side effect objects
> would operate on various versions
> or formats of pure objects,
> and that these were the primary users of the version
> control/specification.
Sometimes, but not always.
For instance, two versions of a Tunes mailing list filter
would like to work on the *same*, original Tunes mailing list,
not on two copies with different address.
Sometimes, you don't want any particular side-effective object,
so the system should choose the best one;
sometimes, you want a precise one.
This does not hold only for side-effective objects:
do you really want libtunes-4.2.2, or would any upgrade do?
do you want it to always appear on terminal1,
or do you want it to appear on whatever terminal
you'll be before next time?
   So one of the problems I've found in the Tunes specification
was that I needed a way to define the limits of an object wrt Migration.
[See HLL/ and Migration/ subprojects].

> I felt that the greatest benefit would be that an
> application would not have to maintain antiquated features in order to keep
> the users happy, yes this could eat up disk space, but
> a) only when no conversion can be provided,
> b) the applications would still share all the code that
> they had in common, which should be quite a bit and
> c) pure/virtual object applications
> should be a hundred times smaller than today's self-indulgent,
> egocentric, in-compatible behemoths.
>
Sure. This means that applications would be made of individual modules,
that you could individually upgrade, convert, discard, etc.
Semantic checking would ensure that upgrades and conversions
don't modify or discard any meaningful information.
Partial evaluation should allow the current version to be optimized
in both space and speed for just the modules included.

>>   I admit I don't have any clear idea
>>about how this can be done, only guesses.
>>I also admit I don't plan to include rightful support
>>for version control in early releases.
>
> this will of course depend greatly on the tpe of object being controlled,
> there will need to be several options
> and it may be that the user/developer/administrator
> sould have a list of options based on what type of control is
> required for a certain object's contents.
> this is a very complex issue
> and IMHO the best solution is to implement all of the solutions
> and let someone else decide
> ( also provide an inteligent selector which can make a good guess )
>
Well, to me, this can be done afterwards through reflection,
so let's first provide reflection.
Using reflection, we could build a log system
that would be enable us to track down modifications.
And by adequately filtering and manipulating the log thing,
we would obtain an efficient version control system.

>>   The key point to managing divergent versions
>>is to achieve good diff and diff3 equivalents.
>>Only Tunes won't work on line-oriented ASCII text,
>>but on arbitrary structures, up to isomorphism.
>
> what do you mean by 'up to isomorphism'?
>
An isomorphism is a reversible transformation
that preserves the structure being considered.
   Well, people could contribute information using
different views on the same objects,
yet only the semantical differences,
not the syntactical ones, are taken into account.
E.g. I use french keywords, variable names, and comments everywhere,
you use english;
I use hexadecimal, you use decimal;
I use EBCDIC, you use ASCII;
I use ";" as a separator, you use it as a terminator.
You like 8-character tabulations,
I prefer 4-character tabulations, etc.
   More abstractly,
you represent lists with cons cells, whereas I use arrays;
you represent things in a way, I in some other.
   Syntax shouldn't count. Only semantics should.
We want to manipulate objects, not representations.
Information about different syntactic views on the objects
may be merged or discarded.
   Of course, what is actually a difference in views
might appear to be a difference in semantics,
until the isomorphism is pinpointed.
My point is that the diff utility should be
able to take into account such a dynamically defined isomorphism,
so that we could both work consistently on the *same* object,
and merge modifications,
while each keeping one's preferred view on it.

>>> so there is
>>> no reason to sweat over functions that may removed.
>>>
>>No need to worry about functions that may have been removed, eh?
>
> by providing version information, redical changes in functionality
> can be effectively managed by an application, because it knows
> what the user was working with when the document was written.
>
Yeah. The version number identifies the semantic context
in which to interpret the object.
Again, semantics-based object manipulation,
instead of syntax-based.

>>Dreaming about Tunes, and a free society.
>
> well, at least one of those will come true.
>
I hope both will, though never perfectly, given enough time.
The problem is, what will I see of it before I die?

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"