Tunes

[Nathan Hawkins]

On Wed, 3 Apr 1996, Patrick Premont wrote:

[register conventions]
> That's one of the things optimizing compilers do, cache the top of the
> stack in the registers. I wrote parts of a simple Scheme compiler which
> did that.

Right. But I'm not entirely sure how optimized I'm going to be able to 
get just yet, with what I'm doing.

> Nathan, what does it mean for you the LLL ? It seems you are defining as
> some kind of Forth. But then the problem of choosing the registers etc...
> is part of the problem of compiling the LLL to machine code.

Yes. I'm working on a variant of Forth, which may be the LLL, if 
Tunespeople want it. And I am trying to build an environment in which I 
can get a LLL->binary compiler working.

> If however by LLL you mean the set of low-level conventions that will
> be used in Tunes, you are talking about something different where the
> choice of registers is relevent.
>
> LLL has been used to describe both so I'm not completely sure what you
> mean. The set of low-level conventions will have to fit in a nice theory
> which will make the HLL capable of choosing the low-level conventions.
> I'm working on that right now (first class representations). It's difficult
> to say at this point if/how you/we should take that into account. Hopefuly
> I'll have something usable before we have invested a lot of work
> in particular conventions... My system might not impose many modifications
> but I can't be sure at this point.

I suppose I'm talking about both.
 
> As for the LLL as a standard low-level language (not the set of
> low-level convetions), I think you should be clear about what you want
> it for. You seem to say that you like programing at the low-to-mid
> level. That's all right but what can Tunes bring to that level ?  I
> don't think that is where Tunes will be special. I think that in the
> finished product, the low-to-mid level programmer will either be
> enhancing the compiler/partial-evaluator or programming at the high
> level. Low level stuff is something to be generated automatically not
> written by hand in large quantity.

Well, that's part of the problem - I'm a low level programmer, not a 
HLL programmer. Hence, I'm not that keen on generating the code
automatically, but would prefer to write by hand in Forth/LL. If the role 
of the low level programmer is to become a high-level programmer, I might 
as well say good-bye now. :( (That's the flame Fare and I had elsewhere, 
do I really need to get into again here?)

> Unless you want to write a lot of low-level code directly, you don't
> need a language like Forth with a syntax, modules, name-spaces
> (vocabularies),... These are considerations for the human writing the code.
> A intermediate stack language (as is often used in compilation) is enough.
> It does not need to have it own character-stream syntax, its programs can
> simply exist as a structure of (Scheme for now) objects in the compiler.
> Giving it a character-stream syntax CAN be done but you start to
> want a lot of language features for humans (name-spaces,...).
>
> If the LLL is to be the (portable) language to which the HLL compiles
> (when it wants to), then Forth would not be the LLL (I wouldn't want
> to compile to Forth) but another language that is compiled to the LLL
> in a straightforward way. But I'd rather have this language be (as
> much as possible) a subset or something similar to a subset of the HLL.

Well, what Fare and I were discussing was more or less doing LLL as a 
drastically modified Forth, with lots of things ripped out, and the HLL 
built on top. I'd do this from the bottom up, myself. But the Tunes 
project seems to be coming from the other end. So the thought was to meet 
in the middle. (At least that's what I thought we were going to do. Fare?)

> > > I need to have some kind of heap management, and I'm leaning toward using
> > > something more like malloc than the Forth setup. I want to be able to
> > > FORGET individual words, as well as whole vocabularies. Normal Forth can't
> > > really do either, which I think is stupid.
> > > 
> >   Who says you have to use Forth?  A Forth like language could be used,
> > taking the best features of Forth, and dumping the bad stuff (I don't like
> > the way Forth handles vocabularies myself).
> 
> If you generate the LLL code from a Scheme program (the compiler,
> which will become a HLL program once bootstraped), then you can have
> "chunks-of-code" object which you can bind to Scheme variables, put in
> lists, whatever... You don't need vocabularies. But we seem to be
> departing from the "Scheme program generates code" model of
> compilation for a "Scheme program applies transformation rules to
> generate code" model. In that case you could probably use the
> environements of the HLL for you vocabularies. I'm just trying
> to unify the language you want with a subset of the HLL as I said earlier.

Well, I haven't been planning on programming in HLL, so my inclination 
runs in the exact opposite direction, with HLL being a superset of LLL. :)
So the Scheme stuff would be build over a more suitable vocabulary 
structure, modified to able to take the punishment. At a certain point, 
we'd reach much the same point, but be a different means. Mostly a matter 
of perspective, I think.

> >   Traditionally, a "process" owns resources.  A "thread" ("task" in
> > Amigaspeak) doesn't.  A "thread" is a resource.  Along with "devices",
> > "files", "memory".  A "thread" is a unit of execution, and in a loose sense,
> > "owns" the CPU, which is a resource, and some memory (out of which it is
> > executing), which is a resource. 
> 
> Unless absolutely necessary, I guess we shouldn't define this kind of
> thing in the LLL. It is the HLL which will guide the selection of
> these things. Hmm.. damn I don't like this LLL/HLL dichotimy at times.
> They are linked so tighly that idealy you'd have only one genius
> desing the whole thing in one piece. Since that's not going to happen,
> we'll need a lot of communication.

Well, as I think I said later in the original message, some parts of the 
system will have to deal with it, and I wanted to know which part. Also, 
I'd like to define LLL<->HLL as being more of a continuum, such that a 
LLL object may interact with an HLL object and vice versa.

As for the specific question of threads/processes, it's a matter of 
context switching, and how much the LLL/processor interface code needs to 
handle, and how much will be dealt with at a higher level.

> > > An alternative would be a design I've been told about, involving nestable
> > > word definitions, like this:
> > > 
> > > : foo : bar ; ;
> > > 
> > > where foo:bar or some related syntax would be used. I think this would be
> > > too complicated, although I as I recall, Pascal allows something like this for
> > > functions. I never used it.
> 
> Hmm... lexical scoping. I take that for granted. Scheme has it. The
> HLL will have it. Why redo it again for a Forth-like language ?

Depends on what does it. Question of will HLL do it, or will LLL. I'd 
like to have it, for the previously mentioned reason that I'm not an HLL 
programmer. The question relates to how to do it so that HLL can get 
maximum use out of it, removing redundancy.

> >   Pascal used it, but the only function that could call the nested functions
> > was the one it was nested in (in your example above, foo could only call
> > bar, since bar was local to foo).
> 
> You mean bar could only be called by foo, the function foo is defined
> in, ... going outward. Note that with proper distinction between
> names and objects, you can only use the lexical name locally but there is
> nothing stoping you from using the object anywhere. In Scheme for
> example, a function can return another function defined in its scope and
> therefore potentially allow that other function to be used outside of
> the scope where it was defined.

That's spc's idea. I'd like to have a workable method of getting at a 
local word from outside it's scope that isn't a total disaster. (C++ :: 
operator, for instance.) Have you read the original message? I was 
talking about a mechanism that allos bar to be called by baz, on a 
lexical level with foo. But only by correctly specifying it. (Which could 
be restricted/able in higher level code.)

*utsl*