HLL and its semantics

[Francois-Rene Rideau]

Patrick wrote:
> - 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 ?
   Attribute is really another name for function, if you consider the
OO<->functional isomorphism as implicit. Let me explain this
isomorphism: in both paradigms, there is a basic abstraction meant to
be universal, "objects", "patterns" or "terms". Objects belong to a
"class" or "type", or are all of the same type/class (SELF and LISP).
In "OO" paradigm, you "send a message" to the object, or
"evaluate an attribute" of the object, or "evaluate a method" on the
object; in functional programming, you "call a function" with the object
as parameter; in both paradigms, this results in a new object being
returned by the message/evaluation/call/whatever, while the "state"
of the object may have been changed (functions can be impure -- see LISP;
and methods can be pure too).
   In advanced OOP (CLOS, Cecil, Dylan, etc), methods are resolved
according to multiple objects, not just one, and in advanced FP, functions
can take multiple arguments.
   Everything that's been done using one paradigm hasn't been done
using the other one, but it could. To me these are just different but
*isomorphic* points of views on things.
   Now that a method consist in reading/writing a field or more complicated
computations, that's also isomorphic to me: that you maintain a counter
a and have methods to access b so that b=a+1, or maintain counter b and
have methods to access a so that a=b-1, or maintain both counters, it's
isomorphic. What is stored, what is computed is a matter of implementation.
There is no reason to give a particular status to contiguously addressable
bits as a one standard compulsory low-level representation. If this leads
to a simple implementation, we may use it, but nothing forbids us to
consider niftier implementation tricks. Semantically, there is no
difference between functions, methods, attributes, annotations, etc.
Let's remove any such difference from the HLL semantics, and let
it to implementers (note that programmers *do* have access to implementation
details *if they wish*, though they never *need* do).



> - Active annotations. (an active attribute?) Are evaluated together
> with the object. I don't understand this.

   Annotations is a new concept I introduce. I had the concept of
"information fields" long ago, that would allow dynamical information
to be gathered on objects, but at the time, I could not produce a
consistent theory about what would be in "data" (static) fields,
and what would be in "info" (dynamic) fields.
   The solution came as I unified both concepts into just one,
because "static" is a transient, local concept. Everything is truely
dynamic, but some things last longer than others, are more stable;
people consider them as static, and a static implementation is
possible; but actually even those "static" things evolve, and
eventually, they will get rewritten, extended, or dropped. Thus,
"data" fields are just a particular, quicker, implementation for
"info" fields which we know will be used enough so that such
implementation yields faster result than a generic one for dynamic
fields.
   Now, annotations being "active" means that you can extend the
semantics of an object. For example, if a function is well-defined
in a context, you can define a finer context, which will conserve
all properties of the previous one, but will add new properties.
These new properties extend to all compound objects made from
the extended objects, and visible in the extended scope.
   To sum up, this means you can dynamically extend the denotational
semantics for objects.


> 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.
   No. I was thinking about function evaluation. You're right I was
confusing. Active annotations are evaluated together with the object
as other objects were combined into it; defining new annotations is
a meta-operation, an operation on the context, not on objects; then
accessing the newly defined annotations is an operation on the objects.
For instance, adding a new field to entries in a database is a
meta-operation; but then, accessing the new field is just a usual operation.


> 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.
   This indeed *is* equivalent to redefining the "apply" function.
Just that this is completely modular. Whereas in previous systems,
there was just a one global "apply" function, now, every context
can have its own version of "apply".
   Thus, active annotations are some way to have "homogeneous"
reflectivity, where reflection does not lead to a one global meta-context,
but to a much more similar world, with local meta-contexts.
   For those these reasons, I think that this feature are *foremost* to
the TUNES HLL, and will differentiate it from other systems.


> - 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 ?
   A context defines the semantics, the meaning of an object.
That is, if you write "1+1", it has meaning in a context that defines
"1" and "+". An object can "see" only what is accessible from its context,
but objects can be accessible from multiple contexts. As the context defines
all the meaning of the object, indeed to copy an object, you need copy only
what matters to the context you're seeing it in; but what matters is the
"observational semantics" in the context, and cannot always be finitely
definable in that context, so to actually copy an object, you need more
than its context, but meta-information about the context. E.g. if your
context consists only of a decrease operator and a "test if zero" function,
what you need to save is a counter, even if the actual implementation was
a list or file in which you advance and which you tested was empty.


> - "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.
   Well, again, I may have chosen the bad words. Perhaps "meta-protocol"
is better ? But actually, this meta-protocol is what manages classes,
and thus objects being instanciated, etc, so if you call classes
"meta-objects", then I was rather talking about "meta-meta-objects" ;)


> - 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.
   I'm not sure what you mean... Types and contexts are different things.
A type defines the properties of an object, but inside a more general
context that explains everything that's known about the universe in which
the object is considered. You could well say that one is an
extension/restriction to the other.


> 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 ?
   I don't know what you mean by "variable", but safety sure is
a relative concept: it strongly depends on the axioms you admit.
As these axioms "vary", yes, safety varies. Different people make
different assumptions; some are ready to trust some software or
hardware more than others do, because they feel they need the
corresponding speed/size efficiency hit, or just they need some
feature they can't have another way. Should I have recompiled sendmail
instead of installing the precompiled binary as a setuid executable ?
Surely not if I was paranoid about security.



> - Coq. It seems the author (I assume it's Fare)
   Yes it's me. Not hard to guess, 'cause I'm currently the only author :( :(

> seems very familiar with Coq.
   Well, I've worked with it, and during this summer, I'll have to
work with it again ! I'm not familiar with everything in Coq (e.g.
tactics programmable in CAML), but I know a bit about it.

> I looked up the suggested pointers about it but it seems to
> require knowledge of advanced logic theory to understand what they are
> saying.
   That may be, unhappily. Their docs begin with lots of formal logic.
The examples given in the distribution may be more explicit. I guess
I'll have to explain this Curry-Howard isomorphism somewhere, too.
Where in the WWW pages do you think I should put it ?

> 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 ?
   Very good question. I'll ask the Coq team...



> I think that's enough questions for now, or maybe too many.
   No that's fine: questions force us to explain things, to say them
explicitly, and thus cristallize our vague thoughts into concrete words.
I definitely need give you all more concrete examples of my wanderings.
See my next message...


--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"