What and Why High-Level (was: peanuts)

[Francois-Rene Rideau]

> If the HLL can talk to the LLL, does it really matter what the LLL is?
   No. But before the HLL can talk to it, it must exist and be define,
doesn't it ? Of course the "before" is misleading. The LLL can and should
be dynamically defined to fit the contradictory needs of the HLL
and the underlying somehow portable hardware model.


>   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?
   No it doesn't.


>>    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).
   To manipulate a program is to modify it, to combine it with other programs
written independently, to extract information from it, to maintain it, etc.
   Given two Turing machine programs, the only easy thing to do is
to execute one program then the other,
which is not a very powerful manipulation.
Hence I declare that the finite-state language used by Turing machines is
not expressive (which incidentally was Turing's point:
with very little expressivity, you can compute anything computable function).
   Similarly, FORTRAN is not very expressive for anything but numerical
analysis (and even then, only if standard tools are sufficient to you).


>   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?
   The language is not important per se. What is important is the
expressiveness of this language.
   By adopting a low-level language (e.g. a Turing machine),
you overspecify the way higher-level languages must be implemented
to properly interface the system.


>   I think you missed my point.  On the Amiga, there IS no distinction made
> between the OS and other shared libraries.
   I never meant that the Amiga was wrong.
Providing a common interface for all kinds of services is precisely
what any OS should be about.
And the AmigaDOS is among the available OSes that do it best.
   The problem is that this interface being low-level
in the case of the Amiga like everywhere else,
high-level services must be reified
in an unsecure information-losing way
before they can be interfaced.


>   It's just that, on the Amiga, all objects (uh, shared libraries) follow a
> common calling convention, eliminating the problems of cross language
> development.
   My point is that a low-level calling convention cannot express things
like pointers having to abide by GC conventions,
lists having to be circular,
numbers being encoded in such way,
restrictions upon values of variables.
   I'd prefer having no static register convention at all,
but ways to specify the semantical behavior of interlanguage communication.
The gain of having a low-level convention is lost many times
when each application has to double-check its arguments
to have little or no warranty for interprocess communication
(what register value will guarantee you that the right dynamical
protocol will be used ?).


>   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.
   Yes. In particular, neither the TPO nor the people who use it
want to even have to think about the way registers are passed.
   If the TPO and TPO-using library come from the same source,
there's no problem. Now, in this case, not only an OS convention was useless,
but it forces implementors to comply to some model
whose adaptation to their problem ranges from bad to disastrous.
   If the TPO and TPO user have different background,
in no way will the standard calling convention help them,
because it cannot help them express anything about the kind of
objects they want to pass around. The OS convention, if used, will
get in the way twice. If not, well, it was useless.
   To sum up, a low-level convention is never useful and always harmful
whenever a high-level problem is to be solved.
It is useless, but gets in the way (sometimes as a huge obstacle).
   Happily, there are (unwritten) high-level conventions
that people follow that allows them to communicate
*despite* low-level conventions.


> At some point, the semantics have to be expressible.
   Which is precisely what a low-level convention makes impossible.


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

   Well, to begin with, the calling convention must be Turing-equivalent,
then it must be as expressive as possible, and we end-up with its being
programmable in the full Tunes HLL.
   Which means that, for instance, if you have a C++ function
   	int& Inc(int& x) {return ++x;}
and a Pascal procedure
	Procedure Dec(var x:Integer); Begin x:=x-1 End
Then you can interface them into
	Dec (<:C++toPascal(my_options):<Inc(my_var)>>)
And it won't be understood at a low-level convention that would
mean lots of marshalling, but it would be directly understood
at high-level which would allow cross-language optimization, etc.

   If two theorem provers are available, and you can express both of
their semantics in some context of the HLL, then you can
define some semantical mapping between them,
that will be dynamically transformed into lower-level conventions as needed,
taking into account existing low-level conventions for
implementations of those languages.
   All these are under full (implicit or explicit) control of the user,
and could be done semi-automatically,
according to the power of available automated tools.


>   And what is an example of more expressive semantics?
   I'd like for instance, to say that object K is to be observed with
a set of observable O, and that its semantics is that the set of
possible modifications is M. Then, I don't care how it is implemented,
but I wish it be as efficient as possible as for cost function C.
   The semantical relations between M,O,C,K should be specifiable in
a language as expressible as possible: it shall include higher-order
logic as well as notions of time, space and communication cost,
and to allow implementation and interfacing of low-level objects,
it should also include as complete low-level machine descriptions as
possible.
   The specification could make the semantical relations explicit,
and let the computer find implementations. Or it could propose an
implementation, and let the computer find the abstract semantics
it understands. Or (ideally) it would give enough of both so that
program execution as well as program manipulation are easy.
   In any case, given these M,O,C,K semantics,
everything is allowed to the system, and the way to express them
is the calling convention. If better ways to express them are found,
the calling convention will be changed, and hopefully, some translator
is expressible in both calling conventions, so that the whole system
may be translated on the fly.
   Pretty high-level isn't it ?


>   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"?
   Current low-level calling conventions merely specify some
name->register/memory-address mapping, and nothing more.
But what's in a name ?
Some "type" information is allowed, but there is no way to make any safe
assumption about it.
This is not even Turing-equivalent
(TM being kind of the least expressive possible useful computer language)
   The more information you get, the higher level you are. See above
for the idea of some very high-level convention.


>   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.
   The HLL itself is precisely this standard calling convention.


>[Supercomputers and Maspars running Unix]
   Unix here is just an interface that cannot take advantage of the hardware,
but allows engineers to have their usual programs
to download programs and upload results.
   Parallel computations on these computers do not use Unix more than say,
PC programs use MS-DOS.


>   Now, how is 42 passed around in Tunes?
   The characteristic of Tunes is that this will not ever be specified.
It could be passed anyway you mentionned, or any other, and the way
could change dynamically. The only important thing is that it will
always behave like 42 to the external user.
   Of course, the initial LLL will have some standard way of doing it,
but only the implementors see the LLL, which may dynamically change,
while completely different versions could coexist and communicate.


> 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?
   To communicate, objects have to agree with each other's representation.
How the agreement takes place, who does what conversion, is left unspecified
at the OS level.
   In practice, at the time the two objects are linked together,
that is before they even know each other,
some common meta(n)-object will choose some convention,
optimizing it or not, inlining as much of parameter passing and function
calls as needed for objects that it knows will be used enough for such
optimizations to be useful.
   Of course, objects need not have the same meta-objects,
but because the system is founded,
you can always find a common meta(n)-object.
   Users are free (and encouraged) to implement their own objects
and meta-objects if they're not satisfied with what exists.
Don't expect miracles from our initial implementation.


--    ,        	                                ,           _ 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/"