Language/Implementation comments

Nathan Hawkins
Sat, 6 Apr 1996 06:56:10 -0500 (EST)

On Fri, 5 Apr 1996 wrote:
> I'm not sure what you're saying but I'm all for programming from
> specifications, automating it as much as possible. I may have
> something to contribute to Tunes in that regard. However in Tunes
> everyone has his idea of what the project is or should be. The project
> seems to be in a perpetual identity crisis. So I'm not sure Tunes will
> end up being what I want it to be. I hope it keeps its objectives.

Yes, that does seem to be a problem. I'm more or less bringing my own 
project into Tunes, which happened to be similar to the LLL/386 project. 
So I have somewhat different ideas about what I want Tunes to be, too. I 
don't want it to be the only possible use for the LLL, as I'd like to be 
able to use it directly.

> I'm a bit troubled by those who wish to use Tunes as a low level
> programming language.

I don't recall anyone suggesting that, and I presume "those" probably 
refers to me... The idea was to include a low level programming language 
in Tunes, which coincidentally allows low level programming for those 
that want it. Hardly using Tunes as a low level language, which I'm sure 
it won't be.

> It is certainely not what Tunes tries to make
> easier. And to me, it looks almost contradictory to try to make low
> level programming easier (because the way to do it is by building
> higher level constructs). Low level programming is important, you need
> it to implement the higher level constructs, once. Then once you have
> a well implemented higher level language, you use it. The low level
> part of Tunes is there to implement the desired high level language,
> and its development should be driven by that goal. So wanting to make
> the HLL compatible with the LLL is having it backwards in my opinion.
> It's the LLL which should comply with the HLL's requirements.  Anyway,
> I don't want to make a big deal out of this, its not a real problem
> curently. I just wanted to say this to help make sure that it doesn't
> become one.

Well, LL is what I like to do, and the idea of stopping my LL programming 
doesn't appeal to me much. The plan I have is to build the LLL, and keep 
on doing that, moving to another processor, if necessary. But I want to 
continue hacking on it indefinately, as opposed to moving over to "higher
level constructs." And the LLL shouldn't just be there to implement the HLL.
It should also be there to allow LL extensions which may be needed from 
time to time, and which LL programmers may be more likely or willing to 
write. Also, some things genuinely are going to work better, or get done 
sooner this way.
Cutting out LL programmers entirely, by requiring the use of HLL's was 
what I flamed Fare about on that other mailing list we're both in. But I 
don't wish to repeat that flame here. Basically, he said he wasn't in 
favour of this, and I called him on it. ;)