HLL and its semantics

[Patrick Premont]

Hello everyone,

here are a few points I'd like to make :

I don't think we need to specify a standard LLL for TUNES.  What we
want is to be able to take a HLL program and execute it.  How that is
done is an implementation detail.  The first HLL (Tunes)
implementations may well be interpreters, in which case a LLL would of
no use as a target language. Also, I doubt a LLL would be useful as as
a host language for Tunes implementations since it's much easier to
implement such a complex programming system in a HLL. A LLL may be
developed for portability reasons in a HLL compiler but it is not
necessary.

The HLL implementation has to be written in itself (or a subset of
itself) since reflectivity is a requirement (one might want to observe
or modify the implementation dynamically). I suggest we take an
existing free (possibly inefficient) implementation of a base HLL
language (like Dylan, or something else that could evolve into Tunes,
let's call it L0), and use it to bootstrap our way to the desired HLL
implementation. If a part of L0 is already written in L0 this is good
because it means we dont have to rewrite that part. We may choose to
rewrite it later to use more of the HLL features once they are
implemented. We may have to change the implementation of L0 to make it
into a more adapted L1 (like allowing low-level access) so we may need
access to L0's source. That's why I think L0 should be free.

Now, I'd like to discuss the proposed HLL semantics (on the WWW) about
which I have quite a few questions. (I realize the document is far
from complete).

- I don't understand what is meant by attributes. The text says it is
like a function but that doesn't fit with my knowledge of the
attribute concept. For me an attribute is some information (an object)
attached to an object (a slot, a field, a record).  We may wish to
only allow access to them via functions, but only PURE functions with
ONE ARGUMENT (the object to which an attribute is attached) that
return ONE OBJECT (the attribute). So my definitions of attributes and
functions are quite different. So what is meant by attribute ?

- Active annotations. (an active attribute?) Are evaluated together
with the object. I don't understand this. Isn't an object only
evaluated once ? Possibly at compile-time ? Should I have read
"executed when the object is accessed ?" If that is so then we need to
know what "accessed" means. We need to know which functions are
considered an access when applied to an object. I could be mistaken
but I don't think this feature is worth including in Tunes. A
user/programmer may always implement it by redefining the "apply"
function to call a "you-are-being-accessed" function on each of it's
arguments.

- Contexts. What is a context ? Is it really a space within which
every object is confined (it cannot refer to objects in another
context). If it is so then that means all it's support objects like
all the meta-objects and the functions to be applied to it should be
copied ? So precisely is a context and what are its intended uses ?

- "An object that verifies or inlines accesses is called a
meta-object."  The term "meta-object" usually refers to the classes,
especially the class of all functions, the class of all classes, the
class of all objects, ...  I think we should stick to this meaning. Or
maybe what was meant is that it is the job of meta-object to verify
acces rigths.

- Types. Why have a seperate access rigth concept when the type system
is sufficiently general and is job is so similar, ensure only safe
accesses are possible. And can the meaning of "safe" be variable ?
(for exemple "won't interfere with this task" and "won't crash Tunes")
How do we determine what safety levels are required when and what to
do when the levels are not met ?

- Standard basic constructors
The word constructor seems very general. I know of type constructors
but the text seems to also include function APPLICATIONS, typed
constructors (what are these?  They are explained in terms of Coq and
in Coq-speech which I don't understand) and evaluation strategy.

- Coq. It seems the author (I assume it's Fare) seems very familiar
with Coq. I looked up the suggested pointers about it but it seems to
require knowledge of advanced logic theory to understand what they are
saying. Is it necessary to know all of this to understand what it does
in more detail that "it prooves things". Is there an introduction
somewhere ? Should we even bother ?

I think that's enough questions for now, or maybe too many.

Patrick