Language/Implementation comments

[Nathan Hawkins]

On Thu, 4 Apr 1996, Justin Sampson wrote:
> Any representation of a computation--be it in Pascal, Haskell, or even
> binary executable code--is an abstraction of the actions to be performed.
> There is no definite ordering among representations, no absolute notion
> of "high-level" versus "low-level." Code written in 80386 assembly can be
> translated to run on a LISP machine, just as code written in Oberon may
> be translated to run on a MISC system.

Certainly, you can do that, and I doubt that anyone would disagree with 
you. Why you would want to is an entirely different, and doubtful question.
Running 386 code on _any_ machine as somewhat revolting. Simulating it 
over Lisp takes that several orders of magnitudes worse, because Lisp is 
almost equally ugly in syntax and semantics. (Personal opinion, shared by 
many.)

> Therefore I suggest abandoning the terms "HLL" and "LLL" in Tunes, and
> replacing them with "Language" (or "Specification") and "Implementation,"
> respectively. The Tunes Language should be general enough to allow any
> abstract representation to be given. The Tunes Computing System will be
> defined in terms of the semantics of the Language; creating some portable
> "low-level language" with restricted semantics would defeat the entire
> purpose of the project. A compact, normalized, partially-evaluated format
> for the Language may be devised, but the semantics of that version must
> be identical to the semantics of the Language. Any Implementation will
> have its own local language, of course, and specifications using that
> language may be easily integrated into a larger program in the Tunes
> Language.

At present, I'm only dealing with LLL/386, so if someone else insists on 
porting Tunes to run over Common Lisp, /I/ certainly won't care. However, I
absolutely do not agree with you. I think you're making a great mistake in
wanting to do the whole system in the HLL. (Speaking as a strictly low level 
programmer.)

And, as has been stated many times, the idea is to merge the LLL and HLL
in the middle, so ultimately, they will become one language. But starting at
both ends, offers many advantages, such as getting some actual code written,
for example.

While a great deal of the discussion lately has been about LL 
implementation details on the x86, don't forget, these would have to be 
done inside the HLL anyway.

> Note that choosing Forth as an intermediate language for all Tunes
> implementations severely restricts portability to currently popular
> machines. The project will surely be embarrassed when a Prolog processor
> is released!

I can't think of any popular machines which will be losing by this 
choice. Enlighten me please. Remember: LLL will be a non-standard variant 
of Forth, retaining the essential features, and losing the obsolete ones.
Any machine we can't port it to probably was already a losing architecture.

As for restricting the choice of implementation language, I don't believe 
that was the plan, and you're welcome to implement it on Prolog, if you 
want. Forth was chosen as the base, because it happens to be the most 
expressive and reflective low level language there is. And, because the 
people who are working on the LLL like Forth. We hope to change Forth into
something new, provisionally called LLL, which is to be drastically improved
over standard Forth.

*utsl*