Some comments on HLL/LLL from the peanut gallery

[Francois-Rene Rideau]

>   And please, don't take this the wrong way.
   There's no way I can ;) Don't take the answer wrong, either...

>   What I mean is, why does the language matter?
   Firstly, any program, including our OS,
has to be written in some language(s).
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.
   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.
If you think Turing equivalency is all there is to it,
then program Tetris with a Turing machine,
use FORTRAN to implement theorem provers,
COBOL to program a tool for formal mathematics,
and /bin/sh to program a word processor.
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);
For instance, Pascal can be simply translated into C.


> 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.


>   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 !


> 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.



>   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.
   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.
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).

   Actually, whatever calling convention you choose,
you can never thereafter interface to it
a higher-level language that have 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.


>   I realize that one of the goals of the HLL is a very safe and provable (I
> still think this is unobtainable, but that's me) language so that it is
> impossible to crash the system, but on the other hand, you don't want to
> force people into only one way of computing either (if I understand you
> correctly).
   Correct.

>   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.


>   Granted, you might be concerned about safety and provability, but just
> make the language it was written in part of the object (even a text string
> such as "PandaStar Haskell 1.7" or "MickySoft C++++--= 2.1" or "Fare' HLL
> 1.00").  If you don't trust MickySoft C++++--=, then the object isn't
> allowed to run.
   Sure such kind of security is very useful; but it just doesn't remotely
replace the kind of security a high-level calling convention provides.
It wouldn't for instance have prevented any of the major software fiascos
we know (e.g. AT&T crash, what's its name satellite lost, Airbus plane
crash, etc).


>   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.
   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.
   And I doubt it can without throttling the performance of the whole system,
because Unix is some bloated coarse-grained monster that doesn't fit such
fine-grained architectures.


>   Besides, we've yet to come up with a language that is all things to all
> programmers.
   And there won't ever be any such language.
However, there are environment that can ensure consistency
between different languages,
and other that cannot.
   And Tunes is meant to implement such environment.

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"