HLL in Scheme

[Francois-Rene Rideau]

> I conciously avoided macros so that we don't have to implement
> them and because I wouldn't know which type of macros to use.
> I think MIT-Scheme's macros aren't the one suggested in R4RS.
> And the ones in R4RS are only a suggestion, they are not part of
> the standard.
   You may be right. But then, we can't escape writing an interpreter
for the HLL-, not a base-level representation of it.


> As soon as the word annotate appears in a sentence, I don't understand.
> What is an annotation ?
   An annotation is anything that is functionally a method or member of
an object, but can be implemented in just any way.
   For instance, you could implement a nth-prime-number function
with a table of known primes, to blow out the too often asked
erathostene sieve benchmark. It could be compressed so as to contain
on one CD the first n billions of prime numbers accessible faster than
it takes to compute (or the same for decimals of Pi).
   Or you could implement a "who's logged in lately" function through a
log. Or a view of a point in a plane as either of rectangular or polar
coordinates with (x,y) and (ro,theta) both being accessible read-write,
and neither being priviledged by the interface. You could implement a
"reader's digest" of messages in a forum where everyone could state his
mind on each message, and further readers take it (semi-automatically)
into account to skip messages deemed uninteresting, etc.
   You could annotate the ANS document for some software with all the examples
you found in a common library, or the examples with the rules concerned
in the ANS document; you could annotate the works of Hegel and Marx by
criticism you (or someone else) made about it, etc.

   The point is, when you define an annotation, what counts is the
semantics, but the implementation is left to the system (which you can
help independently from the specification).
   For instance, after having written some program, you can tell the
system to run it in different ways, but it will still be considered
the "same" program, as long as you didn't change any meaningful
parameter as of its interfaced value.
Meaningfulness depends on the context, so you can try to
change parameters that aren't meaningful in the definition context
for the annotation, but that are in the underlying implementational
context. For instance, when I consider function
 "x -> x + 1",
I don't give a damn about what the calling convention is, whether
the function would get "inlined", how long is the integer representation,
whether it is canonical or not, *as long as* everything looks as if
from the user point of view. No addition or increment instruction may be
executed at all, something may get decremented, or shifted, or multiplied,
a unary constructor applied, I don't even want to know it.
When I annotate a (shared) document, I don't care
if some "canonical" low-level representation for the document gets modified,
if some structure gets completely reencoded to allow the modification,
if the text is downloaded from disk D on computer C,
if a diff file from previous version is made,
or if an external hash table is created, or what else.
I just want the OS to to publish it where I ask,
so it will retrieve it when I ask it.
If I'm not satisfied with performance or price,
then I'm free to overspecify the object or the way it gets evaluated.


> As for the type/object system, you want me to do that now ? We'll
> have to choose a macro system.
   I want us to think about it already, and organize the sources
accordingly, even if, say, file object.scm is currently empty.



> I appreciate the effort you put in writing an actual exemple but
> without undertanding annotations, and with the number of undefined
> constructs you use, I don't understand much of this either.
   Well, what I meant is to describe how we should use the HLL-
itself to define objects we use in the compiler, and how this could look
like: you define an object by a list (the list, if you close the object)
of things you know about the object. Those "things" are such as
the type of the object, how to compute some annotations, precomputed
values, etc. When the definition ends, unspecified things are deduced
from the specified ones, as decided by the implicit context.


>> [Summary]
>>    The HLL- should most probably be implemented as an "open-implemented"
>> interpreter, where most objects' implementation would reflect into
>> HLL- -defined meta-objects, until some special tag is found that the
>> interpreter reflects into Scheme code.
>
> You mean that the behavior of most HLL- objects is defined by their
> meta-object and the recursion stops when the meta-object is a primitive
> which has been built into the interpreter ?
   Yes. And because an object can be seen in different contexts,
the "what is your meta-object" question may have various answers,
as long as all of these are founded.

> Excuse me for rephrasing
> everything you say but I've got trouble undertanding what you
> say when there are occurences of reflect into, tag, context or annotation.
   No harm. It means I wasn't clear enough.


> I assume most of your comments don't mean to stop doing the
> translation and implement what you suggest but rather that we will
> probably change things to reflect your comments as soon as we can
> formalize them ?
   Yes.

> Except maybe for enhencing my type/object system.
   After you send me a bit more documented version of what you're doing,
we'll talk about it.
   If anyone else on the list wants to participate, we may have to
publish something around the Tunes pages...

--    ,        	                                ,           _ 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/"