high level language design

[Francois-Rene Rideau]

> a note: I tend to use some terms in a slightly different way
> than what is generally accepted,
> and some other terms have no generally accepted definition
> I will try to provide all the information
> I can but if something sounds wrong
> let me know and I will try to claify it.
>
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.

> Someone mentioned that the low level language should
> evolve into the high level language...
Yeah. That's the original plan.
Of course, the map is not the land:
if someone happens to achieve the goal first by other ways,
he'll be welcome!

> In the work that I have done I have
> found that three languages are actually a good starting point.
>
> the first is actually a pseudo assembler
> which is capable of managing objects as well as
> most procedural software constructs,
>
> the second is a rather raw behavioural
> object oriented language which provides little internal security.
>
> the third
> is a strict message passing scheme which is highly secure and pure object
> oriented.
>
> the reason for the three levels is in the requirements, each language
> adds some of the requirements  to the final design.  the pseudo assembler
> provides attributes and behaviours as well as the basic software data
> elements, the second level provides a complete object oriented environment,
> the third provides message passing, distributes processing, and system level
> security.
> the second and third languages may or may not have anything in common.
> they
> should not ahve anything in common with the first one.
>
I'm not sure what you mean.
Looks like Corba:
C algorithmic core, C++ class system, and a layer around
to define how processes are distributed.
I don't like systems built in layers.
I want a unified language frame, not three independent languages.

> I was very excited to see that your system will be version aware,
Yes, though I don't have a clear idea
of how this will interact with side-effective objects.
As long as we are manipulating pure objects, there is no problem.
   Perhaps this is yet another reason why we should stress
the importance of having nice (dynamical) separations between
side-effects and functional objects.
See Clean for how to do it the harsh way.
Personally, I think most of what is done manually in Clean
could be done reflectively by the machine.

> I do not know
> if you have considered yet but one of the benefits of this is the use of
> software written in older versions of a language,
> it allows a design to be
> radically changed without having to re-write all previous code.
   Indeed.
However, the more different versions you use,
the more versions you must keep on the hard-disk,
so that allowing multiple versions is not an excuse
for not providing a coherent upgrade system.
   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.
   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.
Hence, all versions for standard meta-format for object interchange
should make it possible to describe small modifications in structures
as small patches to the object -- structure-based diff.
   It seems to me that the easiest way to
achieve seemless production of patches is
to record the "useful part" of the interaction log.
An interaction log also makes object editing reversible,
which is nice for lots of purpose.

> so there is
> no reason to sweat over functions that may removed.
>
I don't understand this previous sentence.
No need to worry about functions that may have been removed, eh?

> I have found that this is
> a key feature in the OS of the future.
>
Sure.

> well I have no more time left this morning, I will try to keep in touch, I
> am not yet on your mailing list, but I hope to get on soon...
I never have any time.
Pupils to teach.
Lessons to learn.
Money to earn.
Contacts to make.
Lots of administratrivia.
Sleep.
Dreaming about Tunes, and a free society.

> thanx for your attention.
Thanks for your interest!

== 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/"