high level language design

[delikat]

>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..

>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 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.

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.  I am at a stage of writing a bunch of low level
code for the basic system objects.  which should be complete in a week or so
there really is not much to do, as these objects are each as simple as i could
make them.  If you would like i can post the code to this mailing list along
with some documentation.  ( as I said before it will be freeware, so I have
a copyright, but don't expect reimbursment. )

>> 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 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.  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. 
>
>> 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.

absolutely.

>   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 )

>   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'?

>
>> 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?

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.

>Dreaming about Tunes, and a free society.

well, at least one of those will come true.


gotta go...
-dav
Dav Delikat ; computer analyst/thinker/father
Jody Delikat ; writer/mother
delikat@mixcom.com ; http://WWW.ripon.EDU/Alumni/DelikatD/index.html
"A good question is never answered. It is not a bolt to be
tightened into place, but a seed to be planted and to bear more
seed toward the hope of greening the landscape of idea."
   -- John Ciardi