The Tunes HLL Semantics


General concepts



Standard Basic constructors

The HLL provides a set of basic constructors. This set should enable it to emulate any kind of other set of constructors.


Standard Library of language extensions



Semantic Difficulties


To merge with this page

Here are exerpts from messages on the Tunes mailing list, that ought to be merged with the contents of this page...
The MOCK paradigm for object semantics
we have meta(n) constructors and destructors.
I'd like for instance, to say that object K is to be observed with a set of observable O, and that its semantics is that the set of possible modifications is M. Then, I don't care how it is implemented, but I wish it be as efficient as possible as for cost function C.
The semantical relations between M,O,C,K should be specifiable in a language as expressible as possible: it shall include higher-order logic as well as notions of time, space and communication cost, and to allow implementation and interfacing of low-level objects, it should also include as complete low-level machine descriptions as possible.
The specification could make the semantical relations explicit, and let the computer find implementations. Or it could propose an implementation, and let the computer find the abstract semantics it understands. Or (ideally) it would give enough of both so that program execution as well as program manipulation are easy.
In any case, given these M,O,C,K semantics, everything is allowed to the system, and the way to express them is the calling convention. If better ways to express them are found, the calling convention will be changed, and hopefully, some translator is expressible in both calling conventions, so that the whole system may be translated on the fly.
Pretty high-level isn't it ?

ATTRIBUTES
> What is an attribute?  I can't seem to figure out the difference between
> this and a function.  You say the implementation may make the difference
> meaningless; but I don't quite understand the theoretical difference.

An attribute can be conceptually thought of as a memoized function:
you have a function that associates some abstract value to some objects,
but want to remember that value permanently without having to recompute it.
* If the function is pure, then there is no semantical difference
 between an attribute and a function
* If the attribute gets garbage collected,
 then all the individual memoized information gets garbage collected;
 if an object gets garbage collected, its attribute disappears, too.
* If you want to be able to associate varying values to objects,
 then use a reference as the attribute;
 that's the ML way of making side-effects orthogonal to other computations.
* You don't want people to read an attribute?
 Just don't export the attribute reader to anyone's scope.
* The exact implementation of attributes is undefined;
 might be fields added to the object's representation;
 might be information nodes inserted in the structure;
 might be a centralized or decentralized association list or hash table;
 might be just anything you can imagine,
 as long as the overall abstract semantics is the same.
 the responsibility is left to implementers (with programmers' hints welcome).

Let's take some usual examples:
* You've got a structure that you'd want to pretty-print, display, or edit.
 Then, you're going to define for every "node" in the structure
 attributes that describe where and how it will be displayed
 (font, indentation, size, color, whatever).
* the system has a concept of "user", built in some module.
 You want to add some accounting/logging information about users.
 No need to rewrite the module that define users.
 Just define a new attribute of users.
 Same goes with password systems, etc.
* you want to type a program. Give each node a type attribute.
 [Note: programs are stored abstract structures, not ASCII]
* you are not satisfied with the way the pretty printer manages
 parts of your program; you ask it to remember the layout,
 or particular layout tactic to use for such parts of the program.
* you want to comment a program.
 Annotate its structure with comments in french, german, chinese, martian.
* you want to translate a program.
 Annotate each node with all the meanings you could find about it,
 before you can understand it and synthetize a translation.
VIEWS
> Does an object have one "real" context, with all the other contexts being
> just views onto the "real" context that limit and restrict (by removing
> some semantics)?

I think that the very principle of reflection is
that there is no "real" context.
This would imply one "real" implementation.
Rather, every object has well-defined semantics
in the context in which it is accessed,
but has some floating implementation:
you can then migrate the implementation
("hey, there's an idle Alpha workstation, let's speed up computations!").
So basically, there are only views on objects.
Of course, if you manage to get a very low-level view on the object
("how does this object run on *this* host using *this* encoding),
then you can be fairly sure that it's "real";
however, as soon as you stop looking at it,
the object might migrate away.
META-OBJECTS
> Does an object have one "definition" meta-object that defines
> specifications for the object?  Is this the same as the "real" context?

Well, a "same" object may have lots of different meta-objects,
as long as they are compatible with each other.
An object gets started by a definition inside some theory;
then meta-object can be specified that refine the abstract semantics
of the object into more concrete operational semantics,
until we get to the bare-bones level where the object is executed.

For both security and efficiency reasons,
not everyone is allowed to arbitrarily manipulate meta-objects:
meta-objects control the internals of the object;
i.e. not everyone can intercept the keystrokes on a terminal
by adding a meta-object to the terminal handler.
Adding an attribute to an object might involve adding a meta-object;
hence not everyone can add every kind of attribute to an object.
TYPE SYSTEMS
> Do you refer to "type-system" and "context" to be the same meta-object,
> that defines semantics of the object?  Are these words interchangeable?

Surely, the issues of typing are important to the semantics of the system,
hence the type system is one of those "meta-objects".

Well, I feel that "meta-object" is too vague a term,
as anything that's at a "meta" level seems to be called that way.
Maybe we should coin new terms to describe precisely what we mean.
CORRECTNESS
> At what point is an object under scrutiny of correctness; i.e. when is it
> proven?  Never, until user requested; or automatically, when created or
> defined?

Well, the system will have user-defined invariants,
and every "context" will include its set of invariants.
The system will guarantee that these invariants are always enforced.
So that when an object is used in a context where correctness of the
object wrt to some specification is part of the invariants,
then you can be fairly sure that the object correctly implements
its specification.
Of course, the system may be unable to enforce some invariants,
but then, it won't provide you the context you want;
only by giving the system the proper hints, you may achieve what you want.

Hence, you write a specification, then ask the system
"instantiate this specification for me", giving it a tactic/meta-object,
or letting the default tactic run.
The system will either manage to instantiate the specification, or fail
(or you may stop it when it still hasn't answered and you are bored).
*Of course*, the instantiation tactic may involve interactive computations
and proofs.
ABSTRACTION & MIGRATION
> Is this an example of abstraction: taking an integer addition function and
> abstracting it to work with floats?

If the addition function is used in a context such that
the fact that the numbers are integers rather than float
does not intervene, then it is a valid to abstract the number
type into something more general than integers.
You reapply the said abstracted object to the float number type,
but the result is not the abstraction itself;
If the overall abstract semantics of the new object are the same
as those of the original one (i.e. you were doing computations on integers,
and are now using the FPU to speed them up),
then it is what I called a "migration" of the original object.
REFERENCES CONSIDERED HARMFUL
It seems to me that references are not a good concept in a distributed system. Communication Channels, Linear objects, and projects seem to do more than references, in more precise ways:


To Do on this page


Back to the Tunes HLL Subproject.


Page Maintainer:
Faré -- rideau@clipper.ens.fr