Basic operations

[Fare Rideau]

Last but not least, here is about (I hope) more concrete aspects of Tunes.

>: David Manifold <tril@bespin.ml.org>, with statements reordered by Fare.


> The object system behind the HLL is a set of capabilities that describes
> all possible languages and methods of inventing new ones.  I call it the
> metalanguage...it is this that I am interested in working on and
> understanding.

Agreed. Now, a few remarks: there doesn't seem to be any
"bestest framework" that be naturally better than every other one
for every subject, though there are "universal frameworks"
that allow to express any other framework then work in it.
Tunes can't be bestest, but it can be universal,
which is still better than non-universal frameworks.
For that, we will have to face choices in which concepts to make primitive,
and which to make compound. Surely, it might be possible to modify the
framework afterwards, but it will be costly, so we must be careful.


> The metalanguage is not really linguistic at all, and I do
> not know how to design the language part of the system.

If you mean syntax, we can forget it at first, and just use s-exp.


> But I do want to
> model the interaction between objects at the most basic level.  I want to
> model reflection in a closed system.  Maybe a system that can go from
> source to semantics to source again is reflective.  But my idea of
> reflection is a closed object system where the system is self-described
> and self-modifiable.  The primitive objects come first, then interface to
> the external world.
>
Indeed, before we can start interfacing to the external world,
and interface programs written in existing languages,
we must have an internal world and language.


> What operations are
> available on the level where syntax is not required?  Previous systems had
> programmers take their meaning and encode it to a language.  Tunes allows
> programmers to directly express meaning by specifying objects.  One reason
> why I am enthusiastic about Tunes is programming without a language.
>
Again, you always program using a language;
the difference is that you can dynamically fit the language
to the concepts, instead of having a fixed language that
eventually gets in the way.
Still, we can try to isolate concepts independently from a particular
syntactical representation.


So the question is: what are the *primitive* concepts in Tunes?


As we saw, our goal is to be universal, that is,
to be able to express any other programming framework,
with its basic operations, their constraints, their meaning,
and perhaps even their cost.
Hence our language must support not only programming,
but also all kinds of logic statements.

Now, there is no static set of operations that will allow
to express efficiently every possible programming framework.
So we have to make hard choice about what will be in our initial
framework, and what we'll have to add later.
Of course, adding things later must be made as easy as possible,
and, reflection should help us not having to make full but clumsy
embeddings of a programming model in another, when we can use partial
efficient embeddings that suffice for the particular programs to interface.
But there will always be intrinsic difficulties at adapting
very different programming models to each other.

Hence, we're back to defining a particular reflective framework
of computer logic, in which we can reasonably do both programming
and specification. I admit that there are so many different possible
frameworks that I don't know yet which is "best" fit.
Approaches that have already proven successful are:
* Pure Functional Language based provers, such as
 the Boyer-Moore prover and its latest incarnation in Common LISP, ACL2,
 or ML-based provers like Coq or NuPrl.
* Logic-programming or Rewrite systems like SPIKE and others.

Most important choices:
* how stringent should be the type system for initial primitives?
 trivial a la LISP, or rich a la ML?
* what programming style to begin with? functions or logic goals?
* should we accept non-deterministic functions?
* should we enforce termination by structural construction?
 if not, how can we safely extend the system?

Note that the least primitives we have, the simpler the initial system,
as the number of axioms tends to grow exponentially with the number
of computational primitives that mutually interact.
But the least primitives we have, the more concepts will have to
be compound, which will bias coding style towards whichever
concepts are less costly.

If you are to start now, my current advice would be to start with something
much like NuPRL (or perhaps NuPRL itself), but I admit I have to investigate
the issues more before I can tell: there are too many systems I don't know
yet.

Best regards,

== Faré -=- (FR) François-René Rideau -=- (VN) Уng-Vû Bân -=- rideau@ens.fr ==
Join a project for a free reflective computing system! | 6 rue Augustin Thierry
TUNES is a Useful, Not Expedient System.               | 75019 PARIS     FRANCE
http://www.eleves.ens.fr:8080/home/rideau/Tunes/ -=- Reflection&Cybernethics ==