Another stab at the HLL ...

[Patrick Premont]

> 
> On some network somewhere in cyberspace, premont@cs.toronto.edu transmitted:
> >
> > I'm not talking about doing occasional low level stuff from the HLL
> > when the HLL isn't adequate. It should be possible to do that. I'm
> > talking about low level programmers programming whole applications or
> > whatever in their custum made language to play with the Tunes
> > internals. I'm affraid nothing but the HLL will be able to allow low
> > level programming since many aspects of the low level structure of
> > Tunes will probably change dynamicaly as directed by the HLL (take
> > data representations and calling conventions for exemples). This
> > dynamism probably won't be there in the first implentations and thus
> > it will be possible to write low level programs until dynamism is
> > implemented. Then we will have to perform major rewrites of the low
> > level stuff (in something more like the HLL) to make it configurable
> > by the HLL.
> >
>   This is EXACTLY what bugs me about the supposed HLL.	That somehow, all
> these messy details about concrete implimentation details will be
> automagically taken care of, somewhere.  Somehow.
> 
>   How?
> 
>   I'm not looking for the final answer.  I'm just looking for AN answer that
> reasonably answers the question.  At at a fairly low level.  As in bits being
> moved about the computer.

Well I'm not going to bo down into the bits since there are plenty of
existing compilers that can do that for me so let me describe a
solution that only appeals to existing languages and compilers.

Let's take the task of writing some routine like the dice throwing
routine you suggested. Consider this very crude solution. Once you
have written your routine, you give names to the input and output type
and representations if you just invented them. If they are already
used elsewhere you give the same names. You also name the particular
convention you want to use for everything that Tunes allows to be
changed (type of multitasking for example). Now all routines that
attempt to pass arguements to your function will have to have the same
name for their output representation as your functions' input
representations' name. A similar constraint is enforced (let's say at
compile time, as you just want AN answer, not the best one) for the
arguments passed out of it. Also the other names like
"coop-multitaking" must match those that describe the current setup of
system (or subsystem).

Now when another routine that uses a different input representation is
build, the calling function WON'T work by themselves. They can't, you
have to specify the semantics of the representations if you want any
of these capabilities. But you can always specify the semantics in
a cheap operational manner by just writing a routine that takes one
representation as input and prodces the other. Now the system can
plug this adapter between your routines to make them "fit". It can
easily be done automatically (take for example C++'s casting functions).

Now this solution is extremely poor. Instead of using names for types
and representations, one should eventually use objects which can be
compared for compatibility and which provide accesor functions to
the "members" in the representation in a nice way. Something like
a class but which is representation specific.

You'll probably be outraged by my first solution which is ridiculously
simple and doesn't do much. What I think will be at the heart of a
more definitive solution is what I'm working on right now, first class
representations. Yeah, I know, I keep mentioning it without releasing
anything. I want to have something that will be implementable (without
a lot of thinking) before I release it.

Now, to come back to my question, do you agree with my comments on the
role of low level programming in Tunes ?

Patrick