Long - Re: Sleeping? Language Design.

[David E. Manifold]

[quoted text has been re-ordered and trimmed somewhat]

On 8 Feb 1998, Joseph E. Van Riper III wrote:

> But if Tunes will not embrace a virtual machine, yet desires to handle
> distributed computing ("Remote Method Invocation," to borrow a phrase
> from Java), it must settle upon a standard language. =20

So one would think.
Tunes plans to take a different route, however.
We will design a meta-language, or framework for preserving and
transforming high-level meaning.  The framework will be reflective, so it
can modify and extend itself.  In this way we can get away without having
a "standard" language. =20

We may need a statically defined interface to underlying hardware, in
the beginning, to use the system.  This would be the Tunes LLL.  However,
if we do have a LLL, we plan to phase it out.  Eventually the translation
from high- to low-level will work as follows:

1. Detailed, high-level specifications for system hardware...
=2E..are combined with...
2. Adaptive rules for translating high-level meaning into the system
hardware context from 1...
=2E..to produce...
3. A decentralized compiler that translates individual objects to machine
format.

> |The actual language features can be added after I initiate the
> framework
> |(consisting of the most abstract concepts).
>=20
> A tricky proposition.  C++ offers and example of what can happen when
> one adds features to a language after the initial framework.  And how
> may one entertain the most abstract concepts without a broad-based
> grounding in several styles of computer languages?

TUNES unifies functional, procedural, stack-based, OO, parallel, and macro
languages.  You will be able to combine ideas from, and translate between,
any of these paradigms, because TUNES is more abstract than any of them.

> Sure, "loops" are in nearly every language, but multiple inheritance
> is not.  And suppose one wished to entertain the idea of visually
> representing the program instead of literally representing it, =E1 la
> Prograph (eg. iconic verses character representation of data
> structures and communications)?

Once you add "loops" or "multiple inheritance" to a Tunes system, you will
be able to use the concepts anywhere in your system.  You can also take
any such feature out, if you don't need it.

The interface doesn't matter.  Visual, textual, or serialized (disk file
or network protocol) are just different ways of looking at objects.  Any
new method you define can be used instantly elsewhere.  Meaning is
preserved and favored, while form is dynamically transformed any way
necessary.  Because Tunes says each object is generic, programs will be
independent from their interfaces as an inherent part of the language.

> We haven't even begun to discuss whether or not such concepts as
> 'multi-threading', 'synchronization,' or 'method-locking' are
> sufficiently abstract enough to consider in the early design of a
> language (or maybe we have and I'm just behind.. if so, my apologies..
> I've been working 12 hour days so I'm lucky I even have a mind
> anymore).

Multi-threading: Every object has the capability of being its own,
separate task.
Synchronization and locking: time-aware specifications are allowed; say
"value x will be unavailable until...", and then if any object tries to
access x it will trigger an exception.  Exceptions are simply when two
specifications conflict.  Behavior in case of a conflict is definable per
context (i.e. for every object separately).

> This language
> will need to be sufficiently powerful enough to handle a broad range
> of concepts, if it's to be Useful and Not Expedient.  Unless I miss my
> guess, Faur=E9 makes his suggestion to study a variety of languages
> not for the benefit of learning the languages, but to grok the
> concepts behind them... that perhaps a new language combining all
> these concepts might be entertained.

[see reply to the next paragraph]

> |At this point, it is my opinion that there is plenty of work I can do
> on
> |Tunes that doesn't require me to learn any new languages.  The
> features
> |from your web pages should be enough.
>=20
> That's probably pretty accurate; I suppose what I'm pointing out is
> that a language for Tunes will likely need more time and effort than a
> single person can carry out, simply because a single person doesn't
> know all the kinds of languages out there.  It might be better to
> assemble a core of people familiar with a variety of languages, and to
> communicate how those ideas are best represented in a language, to see
> if a common language can be derived from the collaberation.

I'm just reading from the HLL pages Fare' has written, and designing a
language that meets the criteria.  From the concepts we already have, any
others should be pretty easy to add.  (Alright, I'm biased, but when I
release a HLL spec it can be analyzed to see what weaknesses it has.)

> I sorta see the possibility of laying down the language, then
> modifying it to include all the interestingly useful benefits of the
> various languages that currently exist, to create the final language
> specification.  Perhaps this is exactly what you're saying, and I'm
> just parsing it badly.

I don't know what you mean by "laying down the language."  I am working on
my own understanding of the language by alternately writing notes and
rewriting them for others to read.  I still haven't reached a point where
I can (or need to) say exactly HOW we should implement the language.

> Is it more important for a user to use whatever language they want,
> and to be able to compile their creation on whatever platform Tunes
> has been ported to, or is it more important to have an efficiently
> running program and cause the user to use a single language for the
> operating system (or endure 'hacks' that convert from another language
> to the common one)?  Are these two even mutually exclusive?

The goal is to make the user never "endure" anything, but to make the user
in complete control of *everything*.  When you said "hack," you meant
"kludge."  Tunes hopes to be the ultimate in elegance, so you will no
longer need to use kludges.

All existing systems were designed around practicality... what can
actually be done on the system... what can get finished in a reasonable
amount of time with a limited number of programmers...

Somehow, every system has made trade-offs between completeness and
expediency.  We no longer need to make these trade-offs.  With the free
software development model (ala linux) we don't have to worry about
"finishing" an OS.  The OS doesn't have to be special-purpose.  So we can
relax and work on the most general-purpose, expressive language we can
think of, and make it easily extendible and changeable.

Thus one of the major benefits of Tunes development is that we are under
no time pressure.=20

> Is it possible to design a single language that embodies all the
> variety of concepts that currently exist in the various programming
> languages available today, make this language port across every
> platform Tunes finds itself designed for (presuming Tunes intends to
> find itself on a wide variety of platforms, to include PC, Mac, Amiga,
> and god forbid, Atari ST), yet be easy enough to use that it doesn't
> require reading a huge tome?  And what about foreign languages?  Would
> it be possible to easily modify the language to provide international
> support (eg. French, German, Japanese, Hebrew, etc)?  And how about
> converting from one human-language over to another human-language,
> while maintaining the same machine-language?  Then there's reflection;
> if I create a method called "spiffyMethod" how do we translate it's
> name to something a non-English speaking person would understand?  Are
> these even issues to concern ourselves with?

The spelling of a function is not important, just what it does.  In Tunes
you can take away everything from a function except what it does.  In
other words, get right to the heart of the matter.

So, if you even put names on your functions, they will be easily
changeable.  (Binding is on meaning, not on name)  Or you could give as
many different names to a function as you like.

> Looking from the bottom up, I have to agree with Faur=E9; using a
> virtual machine is a bad idea because they're notoriously inefficient.
>  Looking from the top down, I can't completely agree with Faur=E9; a
> single language for use on an operating system offers a major
> restriction that alienates everyone but those willing to work with the
> language from using it.

"Single language" is not quite accurate to describe Tunes.
Instead, Tunes will be a different language for every person who uses it.
I think of it as a tool to design your own personal OS.  This way,
everyone CAN have their own "dream OS".

> [tokenized language]
> There's one big potential problem I can see...
>=20
> If the language the developer uses converts to another language with
> its own idiosyncracies, how will s/he be able to ensure s/he optimizes
> their code to best work in the other language from within his/her own
> language?

Yes, isn't this recurring problem with all current systems?  Down with all
mandatory idiosyncracies.  The old meanings of the terms 'language' and
'convert' will become obsolete with the introduction of TUNES.  Language
will no longer be a fixed, defined entity.  Conversion will be done every
day, not just every once in a while and with great difficulty.

> [...]
>
> I say again, I'm not suggesting a virtual machine.  I am not thinking
> there would be some daemon reading a stream thrown at it and either
> spewing machine-code that disappears after a garbage collector eats
> it, or interprets the thing byte by byte (or even word by word),
> carrying out instructions.  I'm thinking of code (perhaps a daemon, if
> it's appropriate) that reads a stream thrown at it, compiles it into
> machine-code, and saves it to wherever it should be stored.. if stored
> in memory, it disappears and would need to be recompiled again, ergo,
> 'virtual' in nature.. if stored on harddisk or the like, it may be
> used just like a regular program.  The stream it reads would be just
> like any old language, except in this case the language is tokenized
> so the stream could be read (if marginally) faster than a standard
> text file.

By daemon, if you mean coarse-grained background task, we won't have any
of those.  If you just mean any object that is constantly running, again,
that's not necessary.  Every object can be independently evaluated
whenever it needs to be.

For the different stages of translation of any object, you can specify
which you want kept permanently, and which you want recomputed every time.
However, mostly the user won't specify either.  The system can just decide
what is better at the time.

A tokenized form, or any other form, can be used, but you won't have to
even know what form it is because it might change the next second.
Now, to start up the system we might use a specific format, but we're not
to the point where we need to discuss it yet.

David E. Manifold <dem@pacificrim.net> http://www.pacificrim.net/~dem/