some HLL comments
Fri, 17 Mar 95 23:03:47 MET
>>> Byte Magazine, vol. 8 no. 9
>>> pp. 356-373, September 1983
>> Well, this will be difficult for me to check out ;( ;( ;(.
>> Is there any way to scan and/or OCR/type the page ? Ark.
> Too bad. I'll type in an Echonet program from the magazine so you
> can see what it looked like ( I got a message from the author saying
> it is now calles Purma and that he is still working on it ):
If you have any more pointers, I'm interested...
Sounds like a nice language...
>>> [ ideas for changable syntax ]
>> I think that by separating the syntax from the semantics, semantics from
>> internal representation, and having automatic rewrite, we can manage all
>> these difficulties cleanly.
> Maybe having separate HLL and LLL is not such a good idea? How about
> extending the LLL to the HLL ( and beyond :-)
As I said in a previous message, the HLL and the LLL are only different
perspective on the very same thing: the language that defines TUNES.
Those two perspective see the same objects, with more or less difficulty;
which objects will be attributed to which subproject will depend solely on
which subproject will have reached this object before the other.
Thus, one may equivalently consider the HLL as an LLL extension, or the
LLL as a HLL restriction. There is no more clear cut distinction between
the two than there is between the "OS" layer and the "application" layer.