Languages

[Francois-Rene Rideau]

">>>>>" is JVS
">>>>" is me (Fare)
">>>" is Mike
">>" is me again(Fare)
">" is Chris


>> portable high-level system. Nothing should prevent us to eventually
>> redesign the LLL (i.e. the set of primitives) and still use "our system"
>> so that a simple recompile will have the same applications running !
>     I'll agree in theory, although I'm not sure what you have left in 
> "our system" if we remove the primitives....
  We should depend on these primitive as much as C depends on the
underlying architecture's instruction set: not at all. Which does not
mean C won't use it: actually, our LLL should be so well designed that
no sensible person would wanna change ;> aint it, Mike ?
  That is system *execution* is founded (no chicken & egg problem), but
system specification need not be...

>     Where do objects fit in with our grand design, anyway?  Toolboxes are
> neat, but they aren't objects.  Where does the high-level OOP stuff come
> in, or is it just an illusion maintained by the compilers?
   It's not an illusion. Well the syntax is an illusion; but the semantics are
everywhere: just no code that wouldn't be approved at high level may be
executed (of course, there are special "approve it !" orders possible for
priviledge users, or inside virtual boxes for the owner of the box).


>>%% Functions can be constants or variables !!! Being constant or
>>%% variable has *nothing to do* with being active or passive...
>>    Why shouldn't I be able to assign
>> "click_event_handler := my_click_handler",
>> or pass a function as a parameter to a generic sorting algorithm ?
>> Have you never heard about functional programming ?
>> SELF or BETA object-oriented programming seem highly isomorphic to
>> functional programming to me...
> 
>     Are you sure you want to do this in the LLL?  (That's what this
> discussion's about, right folks?)  It sounds like you perhaps would like
> to abolish the LLL altogether, and move right into the high-level stuff.
> I will agree that SELF and BETA are great languages for high-level stuff,
> but I can't figure out how you're going to impliment all this.
Yes I'm sure the LLL should map well such manipulations. Virtual machines
commonly used as byte-code target for Lisp or ML, etc, do that everyday !
Why restrict the power of our LLL to manipulate only first-order objects ?
LLL does not mean "manipulate low-level objects only" but "low-level
transformations on object", that is, transformations that involve actual
representations of objects in some implementation model.


>>> Again, you're mixing up the library part with the kernel part.  One
>>> part of the kernel says to another, I need some mem, give me a block.
>>> That's pretty fundamental.
>>    You're confusing kernel and device drivers. Actual memory move is
>> let to some hardware interface -- a device driver. There should be no
>> such thing as a monolithic program that everyone calls. Just have
>> everyone do things directly, call directly the good other object it
>> needs, etc. Some object uses a (persistent) memory object (which in
>> turns uses a raw memory object); it also uses a sound object, and a
>> graphic device object (which calls the hardware memory object to access
>> video memory). All the calls are *inlined* by the compiler (which is
>> automatically activated at run-time if needed). No need to inline the
>> calls by hand in a particular system to obtain some static, monolithic,
>> unmaintainable, badly interfaced, program.
> 
>     Okay, I think this has been your best display of your idea of a 
> kernel-less system.  Some of these concepts seem a tad bit strange, 
> however.  You want a memory driver, yet you need to work with memory in 
> order to load/use it.  You want a CPU driver, yet it would need to use 
> the CPU to run it.  If you can explain how this would work, and the 
> overhead wouldn't be too high, this sounds like a good idea.  (BTW, what 
> kind of messages could you send to a CPU object?  Surely there would be
> some primitives defined there, no?)
   Again, at execution, we have a founded system. Founding the system is the
usual bootstrap problem (need of original cross-compilers and
cross-assemblers). But once you got the system running, calls to the memory
object by the driver than manages further links to the memory object are
already inlined. So really, this is not the difficult problem.
As for the messages to the CPU object, these are the binary instructions,
once properly inlined !!!


>>>>> 	5. 32 bit integers
>>>>> 	6. reals
>>    I agree our implementation dependencies will be 32 bit, etc. But we
>> shouldn't ever build the whole system around these. That is, I talked
>> about implicit choice by the system; the implementation will thus reply
>> 32 bit integers when asked for its standard fast integer type; but we
>> shouldn't explicitly make everything 32 bit.
> 
>     What part of the system would you "ask" for a fast integer?  The CPU 
> object?  The memory object?  The LLL object?
The HLL object will be given some size restriction. An HLL to LLL compiler
will maintain such restrictions, and chose at best for these to be fit
uniformly. The LLL interpreter will then be translated to assembly with
the effect of mapping such sizes to actual local integer sizes...



>     Is this possible to both do this and make them all compatible?  I 
> could see something like the BETA pattern model being able to support the 
> majority of the OO concepts, but even that lacks the power to express and 
> kind of object.  Don't we have to draw the line somewhere, or is our 
> system going to be infititely expandable?  =)
    To me, it's undoubtfully more like going infinitely expandable...



>>    So what are we argueing for actually ?
>>    I just want such kind of instructions/friends be part of a (standard)
>> module for our system, and not have it (or actually have anything)
>> hard-wired. Nothing should be hard-wired. Everything should be plugged, and
>> unpluggable (least you furnish the solder-iron plus manual and plans).
> 
>     Okay, so everything has to be modular.  But does this really mean we 
> can't have primitives?  Not constant primitives, but ones you can use?  
> (Gotta have something to compile the HLL into....)
Again, the implementation has primitives; those map to some HLL constructors
somewhere. But the same constructors may have several different primitives,
"friends", or other HLL mappings. Again, execution is founded; specifications
need not.


>>>> I completely agree there is heterogeneity; what I want is smooth
>>>> interaction
>>>> and communication between different objects, and eventuality of a direct
>>>> access between any indirectly linked universes.
>>>
>>> That may not be possible.  Remember everything goes to machine code and 
>>> runs with the kernel.
>>    Everything will *dynamically* go to machine code, and the dynamics is
>> controlled by the HLL.
> 
>     So the tunes "world" revolves then around the HLL?  What if we wanted 
> a secondard HLL, that would be treated with equal respect as the "normal" 
> HLL?  Isn't it too non-modular to give a high-level construct control of 
> the whole system?
   Another HLL would be expressed in terms of our. That's why we need the
most powerful HLL ever; which is possible. Power sometimes come from
simplicity (see SELF). To map another HLL syntax to ours, we must include
in our some powerful macro system (that's the hard trick that nobody is
known to do satisfactorily in a HLL; but FORTH does it quite well in a LLL,
me thinks).


>>>  All that matters is that the kernel provides
>>> services for different processes to communicate.  It doesn't make sense
>>> to stipulate a development environment (say MOOSE) to HAVE TO be able to
>>> talk natively with a VBX application.  The LLL/kernel provides the
>>> functionality, use it who may like it!
>>    No hard-wired processes, no hard-wired communication. Chips are
>> hard-wired enough. Why build some virtual hardware ? Let's build some
>> real software, and allow full software freedom by not hard-wiring any
>> calling convention, etc, in the specifications (but of course, objects
>> will communicate iff you can find the correct plugs, i.e. you can
>> ultimately find a common calling/communication convention).
> 
>     Possible, although this would be dangerous if people starting making 
> too many calling conventions.  I guess you really need to explain what 
> your concept of an object is here, since in my mind right now, I can only 
> see a bunch of question marks shooting s'more question marks back and fourth.
> 
>>> Here's my little speech about scoping;  I propose we have the union of a 
>>> method and data.  If you want the data, the ONLY way to get it is to ask 
>>> the method.
>> Again, why differentiate arbitrarily kinds of objects ?
>> Let us only say that there are internal subobjects and exported
>> subobjects. That's all. Being exported or not is orthogonal to being of
>> some functional type or not...
> 
>     Sounds good (I think).  The only difference between the two might be 
> a bit or three in a header, true?
> 


>>>>>[about blocks]
>>> Separate the users from the progammers (see previous thread).  A block 
>>> will be a system primitive, users won't see it!  Maybe even HLL 
>>> programmers won't see it.  You can't use those arguments against a 
>>> low-level primitive.
>>    Yes I can. Blocks should be provided in some abstracted LLL library, not
>> as a standard primitive of the LLL kernel. The LLL kernel should be minimal;
>> you told it yourself. And the Scheme vs. Lisp or RISC vs CISC (and MISC vs
>> RISC ?) experience show that you should never multiply language axioms.
>> KISS. Blocks will be included in some system library (again, never worry
>> about efficiency -- human/computer optimizers can do it well for you later).
>> The library will present blocks as some quick and simple implementation of
>> arrays -- a point-modifiable version of functions from an index set to
>> another set.
> 
>     These libraries (implimented as objects?) could then provide a sort 
> of compatibility across LLLs, couldn't they....  I'd once again like to 
> agree, but I'd again need more details about how the libraries are 
> implimented and how you impliment a LLL without such primitives....
You can implement the core of the LLL and those libraries completely
independently, even if both are implemented in assembly. Separate modules
have separate implementations. Remember that our system should allow
transparent inlining. Let's not hand-inline anything.


>>    The problem is the semantics of the decomposers; how they are added or
>> selected, how the user can interact with it, etc.
>>    Linux has its decomposers: they load a.out, coff and elf files (ok,
>> not for our virtual machine; only for the local processor), and root may
>> add kernel modules to support more. And nothing prevents you from writing
>> your own user process that will load any kind of file.
>>    You see the difference:
>>    That's not how I see it. Everything is user-definable to me. It's not
>> the LLL kernel calling the decomposers, but the decomposers calling the
>> LLL kernel to me. There is no such thing as a "system kernel"; there are
>> only object freely interacting, the LLL being one of them (a standard one).
> 
>     I think if this was done right, its simplicity could extend a lot of 
> power to the system.  (Kinda' reminds me of self again....)  Of course, 
> the LLL is just another decomposer, is it not?
Ditto.


>>    Fat is not for the 99% code that needs not be fast or may be compiled
>> easily. Fat is just for that irreducible 1%. It is *needed*. If you're
> system does not support it, it will suck rocks.
> 
>     Okay, so now our "objects" (still need a definition) can include code 
> in any language, including the native processor.  I take it this is how 
> the SLL (super low-level) objects (ie CPU driver) works without a kernel....
Ditto.

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
MOOSE project member. OSL developer.                      |   |   /
Dreams about The Universal (Distributed) Database.       --- --- //
Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE   /|\ /|\ //
Phone: 033 1 42026735                                    /|\ /|\ /