Some comments on HLL/LLL from the peanut gallery

[spc@gate.net]

On some network somewhere in cyberspace, Francois-Rene Rideau transmitted:
> 
> >   And please, don't take this the wrong way.
>    There's no way I can ;) Don't take the answer wrong, either...
> 
  I promise I'll try not to 8-)

> >   What I mean is, why does the language matter?
>    Firstly, any program, including our OS,
> has to be written in some language(s).

  Right.  That's a given.

> To ease everything, choosing a one language that fits is the best choice.
> Because none available fits, we're developping the HLL.
> But to ease portable development of a compiler and libraries,
> we also write a LLL.

  Well, I can see how no existing language does what you want it to do, so
yes, I can see you designing a new HLL.  Fine.  But I'm also seeing some
debate as to how to impliment the LLL.  What I'm saying is that, does it
matter?  If the HLL can talk to the LLL, does it really matter what the LLL
is?  

  If Tunes is just a collection of objects that communicate with each other
(unless I'm mistaken again), does it matter what the object is written in,
as long as they can communicate?

>    Wouldn't any language fit ? No.
> Albeit the famous "Turing equivalency", language expressiveness
> does not lie only in what functions
> can be implemented, but also how easily programs can be manipulated.

  Define manipulated.  Do you mean, can a program generate code that can
then be executed?  And define easily.  I can do that in C (but maybe not to
your definition of easy).

> If you think Turing equivalency is all there is to it,
> then program Tetris with a Turing machine,

  Could do a one dimensional version of Tetris.  I think a two dimentional
version of Tetris could be done on a Turing machine which allowed movement
of the R/W head left/right and up/down.

> use FORTRAN to implement theorem provers,

  For mathematical theorems, I could see it being done for a subset of all
mathematical theorems.  I can't see any program in any language being able
to prove all (currently known) mathematical theorems.  

  Heck, it took several centuries for Fermat's Theorem to be proved by the
best computers in existance, the human mind (and that's assuming the current
proof is accepted).  But we're digressing here ... 

> What counts in a language is the semantics, not the syntax.
>    You can consider a partial preorder among languages
> (including languages where features are forbidden,
> like the language of all valid C programs without architecture dependency)
> by saying that language A is more expressive than B
> if there is a simple enough representation of B into A
> (simple should be something like computable in linear time
> with memory usage linear in the depth of the typed syntax tree,
> and with preservation of some type constraint);

  Huh?

> For instance, Pascal can be simply translated into C.
> 
  Oh, why didn't you say so? 8-)

> 
> > All this focus on one language is promoting the myth
> > that a "portable OS"  has to be written in one language.
>     Not only do I think that promoting a one language syntax is not any good,
> but I refuse to promote even a one language semantics,
> not to talk about a one low-level implementation model:
> though initially Tunes will have only one implementation,
> the specification won't be the implementation;
> some objects may be implementation-dependent,
> but none will need to be.
> Various OS components could be developped in semantically different
> languages (e.g. some pure logic programming language, and some
> imperative object-oriented one). When combining objects having
> different semantical validity contexts, any valid semantical bridge
> can be used, not just the one defined by some low-level implementation.
> 
  Isn't that what I just said?  That it really doesn't matter what language
Tunes (or the OS or the objects) are written in?

> >   Yes, Unix is written in C, but there isn't anything keeping it from being
> > written in something else, say, a souped up Pascal.  Who would know the
> > difference if you could still write code in C?
>    Because souped-up Pascal and C are semantically equivalent, this is
> only a syntactic difference. Now, trying to write Unix in Prolog or plain
> BASIC (dunno about recent ones), or SML, would be quite a different task,
> not to talk about mixing those languages !
> 
  And trying to do AI in C is a different task than what C was originally
designed for, and yet it's been done.  And there has been an OS written in
LISP, so really, nothing surprises me about what language can be used (or
abused) in a given situation.

> 
> > In Unix, really, the only important thing is the API.
>    In any software, what counts to the non-implementers is the interface
> and its semantics !
> 
> > As long as there was a consistant method to
> > call the OS that both sides (the usermode program and the OS), who cares
> > what the OS, or the app, is written in?
>    The OS is not a mere library that programs get linked to that run
> independently, as you suggest (following traditional myths).
> Programs need interact to be useful. Your way of doing things only
> allow programs to communicate with the OS, not to communicate with
> each other (see below); plus you create an arbitrary distinction
> between system and apps, which is just semantical overhead and bloat.
> The OS should be an environment that allows programs to interact safely.
> 
  I think you missed my point.  On the Amiga, there IS no distinction made
between the OS and other shared libraries.  One of the things I started
experimenting with (but didn't get too far as other commitments had higher
priority) was doing an application as a shared library, such that it could
be run stand alone, or used from within other apps (that knew how to this
particular shared library).

  Or, to take another look, any app on the Amiga can be a shared library (in
theory that is.  Practice is another thing, but that's beside the point). 
So, if you look at a shared library as an object, then you have an object
(one shared library) using another object (another shared object).  The
object (shared library) in question does not have to be the OS.  It can be
another non-OS object.

  It's just that, on the Amiga, all objects (uh, shared libraries) follow a
common calling convention, eliminating the problems of cross language
development.  An object can be written in Assembly, C, BASIC, Fortran,
Forth, Pascal, Modula-[23], E, LISP, Prolog, dBase, Rexx, or any other
language for the Amiga.

  On the Amiga, there are no real distinctions made between the OS and other
shared libraries.  Apps can be shared libraries as well, it's just hasn't
been done to my knowledge.  If I can do that, then there is no distinction
between an app and the OS.

> >   A good example of what I'm talking about is AmigaDOS [...]
>    The C, assembly, and BCPL parts of the AmigaDOS
> all comply to the same memory management and calling convention model,
> the same low-level semantics.
>    Now what if someone wanted to interface
> some high-level module to the AmigaDOS, say a tactic for a theorem prover ?
> He couldn't do it,
> because the input and output conventions of his module,
> that takes formulas, subtactics, and continuations as parameters,
> assumes garbage collection, etc,
> aren't expressible in the low-level semantics of the AmigaDOS.

  Say what?  

  Okay, I now have this theorem prover object (TPO).  In order for me to
even begin to communicate to this TPO, there has to be some way to get data
INTO it, and data OUT of it.  Period.  And eventually, the CPU is going to
have to copy some data INTO it, and copy data OUT of it.  At some point, the
semantics have to be expressible.  
  
>    Sure, he could write his own system over the AmigaDOS,
> much like you can write any program over any Turing-equivalent system.
> But that's no more using the AmigaDOS and interfacing to it,
> that's writing an OS over another one,
> and people who would develop other theorem proving tactics
> wouldn't be able to have their programs communicate with his own.
> 
>    So no, the language used doesn't matter, as long as you find a
> ground for languages to communicate.

  Isn't that what I've been saying?

> In any available OS, this ground is
> a static, language-independent, low-level calling or linking convention,
> up to whatever syntactic sugar a language may put over it;
> because of the low-level nature of this convention,
> no security requirement is expressible,
> so you just have to pray for other apps not to interfere with yours
> (which good programmers avoid by following strict unwritten conventions,
> and not limiting as much as possible the way programs interact).
> 
  Do tell.  What, pray tell, is a high-level calling convention?  I would
like an example please, because saying something like, "Oh, well the method
that the HyperAI Language uses" isn't telling me a whole lot.

>    Actually, whatever calling convention you choose,
> you can never thereafter interface to it
> a higher-level language that have more expressive semantics.

  And what is an example of more expressive semantics?

> Of course, you can still interface
> some services available from the lower calling convention
> to higher languages,
> as is done in any reasonable implementation of a programming language;
> and you can always interface
> a particular implementation (perhaps a de facto standard)
> of the high-level language
> to the low-level convention.
>    But in both cases, the interface will be completely unsecure
> and won't be really an interface between the languages.
> a lower-level language to some particular implementation
> of the higher-level language. Moreover, the interface won't
> be adapted as for efficiency to the particular programs that
> get interfaced.
>    That is, a low-level interface is but semantical and implementational
> overhead.
>    Some kind of interface is needed, though, and often, a low-level one
> is the easiest to implement. Some OSes do it well (e.g. AmigaDOS);
> some computers do it bad (e.g. MSDOS). But this is precisely the kind of
> old technology that Tunes wants to transcend. We do not want to port
> AmigaDOS to another platform. We want to bring a new generation of OSes.
> 
  And I'm having a hell of a time understanding what you are trying to
acheive here.  At what point does a calling convention stop being "low
level" and start being "high level"?  

  And like I said, most of the time I program on the Amiga, I'm not aware of
the calling conventions.  It's the job of the compiler to turn this:

		DosBase = OpenLibrary("dos.library",STD_VERSION);

  to

		move.l	#text.dos.library,a1
		sub.l	d0,d0
		move.l	ExecBase,a6
		jsr	_LVOOpenLibrary(a6)
		move.l	DosBase,d0

> >   So, an object can be written in any language available, and as long as it
> > follows the standard calling convention (or the calling convention can be
> > discribed so that other objects can call it) it doesn't matter what it was
> > written in.
>    Yes. But to describe the calling convention of a function from an
> arbitrary language, you need a very expressive meta-language. Just mapping
> argument names to registers ain't enough, as the way arguments are to
> be decoded, the restriction over pointer structured usage, the way stack
> and heaps are used, the real-time requirements, the multithreading
> cooperation, the argument validity constraints (e.g. such cryptographer
> requires prime numbers), etc, are all important.
>    So a standard calling conventon shouldn't be low-level.
> 
  Did I ever say parameters have to be passed in registers?  They can be
passed in by cyber pigeons for all I care.  But this insistence that Tunes
be written in HLL (and the LLL) I think is the wrong way to go.  Use
whatever language is best suited, but come up with A standard calling
convention to be used between objects.

> >   Unix proved (beyond any doubt) that an OS can be ported to just about any
> > hardware in existance.
>    Unix has been ported to all conventional hardware, because all these
> follow the same low-level model; moreover, whether unix alikes on computers
> without an MMU is unix is a good question.

  It probably is.  There are versions of Unix for non MMU based CPUs. 
They're quite small, and usually based upon Unix Version 6 or 7, but they're
still Unix.  But to say that all the systems that Unix has been ported to
are the same low-level model is ludicrous.  It's been ported to the Intel
80286, and that's pretty far out there.

>    Unix hasn't be ported to the Connection Machine, or to clusters of MuP21's,
> that is to parallel computers made of lots of CPUs,
> each one not very powerful, with little memory, and no MMU.

  But the Crays run Unix.  And I think the Connection Machine has a front
end workstation (wouldn't surprise me if it runs Unix) where the code for
the program for the Connection Machine is stored and loaded into the
Connection Machine.

  I know that the Maspar at the school I attend has a Unix front end, and
the machine itself doesn't even run an OS.

  Okay, time for an example.  42.  It can be respresented, in the computer
(sorry to inject some low-level concrete reality here, but I have to ground
myself somewhere, so here it is) as:

Character:		*
Byte:			00101010
Integer:		00000000000000000000000000101010
BCD (4 digits)		0000000001000010
Float (32 bits)		01000010001010000000000000000000
Double (64bits)	        0100000001000101000000000000000000000000000000000000000000000000
String (C)		001101000011001000000000
String (Pascal)		000000100011010000110010
Fixed point (24.8)	00000000000000000010101000000000

  And some not so concrete ways:

			42
			6 * 7
			2 * 3 * 7
			126 / 3
			meaning of life

  Now, how is 42 passed around in Tunes?  Do the two objects have to agree
upon the representation of 42 (or the parameters in general), or do they
register their perceived representations to some other object, and that
other object then has the responsibility of converting one perception of 42
from one object to another perception of 42 to another object?  Just what is
going on in Tunes?

  -spc ("What?  You mean you don't understand "meaning of life divided by
	the Trinity?"  What type of system are you?")