Languages

[Chris Harris]

Wow!  Quite a long thread we have going here.  Hope something useful 
comes out of it....  =)

">>>>>" is Fare
">>>>" is JVS
">>>" is me again
">>" is Mike
">" is Fare

On Wed, 14 Dec 1994, Francois-Rene Rideau wrote:

> > The primitives are 
> > implemented by the kernel, and should be with us forever?(!).  Everything 
> > else builds on these. 
<snip>
> 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....

>    Which leads me to another topic (to be discussed in another message
> thread): what kind of API will we offer to users in what languages ?

    This is really a topic for another thread, but I'm not sure we want 
to discuss it now, are you?  APIs are a fairly high-level thing, so 
unless we know what we're doing low-level wise, we can't really do much.
    I'd be willing to bet that the APIs will be more difficult to agree 
upon than the LLL, by a lot.  Its simply that every programmer/user has 
their own style, and if the OS is as configurable as we'd like it, 
standardization will be a nightmare.  Supporting multiple APIs would be 
okay, but it would take a up more space, and make things harder to hook 
together....

> > That may not be possible and may actually cloud our judgement if
> > me mandate it.  As was previously mentioned (Johan?), heterogeniety has 
> > its place.
>    Again, I'm not against any kind of heterogeneity, but against compacity:
> however heterogeneous the objects, if there is some way in which these
> objects may communicate, we shall provide it.

    Sounds good, but I'm not even going to think about what level the 
communication stuff goes on....
    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?

> >>> A. "Passive items" -
> >>> 	1. constants
> >>> 	2. variables
> %%   And why do you call it "passive" ? Functions can be constants or
> %% variables !!! Being constant or variable has *nothing to do* with
> %% being active or passive...
> > I don't want to put words in Johans mouth, but, passive items do not act 
> > on others.  A variable (passive item) does not modify others, code does...
>    No ! No ! No !
>    A variable or a constant may well contain some function or other code.
> Shall I repeat myself ? The "%%" quoted lines say it all.
>    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 seen Scheme, Lisp, FORTH, ML, Miranda, BETA, SELF ? Have you never heard
> about functional programming ? I'll let jch (some friend of mine who's just
> joined the list) expand on functional programming; but 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.

> >>> 	3. blocks of memory
> >>    All computers do not have a linear memory model (see hardware LISP
> >> machines, or software virtual machines of any kind that may be the
> >> underlying system).
> >>    That's why I think that memory blocks are some very low-level
> >> thing whose use should be decided by the optimizer (whether human or
> >> computer), not the high-level programmer (sometimes the same
> >> human/computer, though); but in concertation with him (high-level
> >> annotations may help the optimizer decide).
> >>    I'm not saying that our LLL won't provide these, but that it
> >> shan't be a part of the grammatical kernel of our system, just one
> >> of the lowest-level
> >> (and very important) of the standard vocabulary (library).
> > 
> > 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?)

> >>> 	5. 32 bit integers
> >>> 	6. reals

<snip>

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

> >>> 	4. pointers
> >>    Here should be the basic abstraction of the low-level side of our
> >> system. The low-level begins with pointers. Local pointer size is
> >> host-defined;
> >> pointer size inside a file may be file-defined (or sub-file defined).
> >
> > Nope. Remember we're talking LLL.  Your HLL may create as many 
> > abstractions as it wants until it runs out of memory or is blue in the 
> > face.  But we're talking fundamental/primitive instructions here!
>    We're not talking only LLL, but the specifications of some generic
> binary encoding format that must be able to express any kind of objects !

    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?  =)

> Even if we were building "only" a LLL, this LLL is meant as a portable
> target language for compilers, not as the the foundation language for
> all further user interaction. Again, we should be able to replace the LLL
> without changing the semantics of the system: persistence, distribution,
> unity, high-levelness.

    I will agree with this one.  Probably not something we want to do 
without thinking long and hard about it, but it shouldn't be impossible.

> >>> B. "Active items"
> > Again (again again again), I believe your mixing HLL with LLL.  The HLL
> > may be able to view all of these together, but to get something off the
> > ground, we need to establish our basic command set (verbs).  A friend (if
> > I'm reading this correctly is a chunk of code/function/method whatever,
> > and an object is a convenient way of grouping these together.  Am I on
> > target Johan?
>    Why not call these by their name ? Instruction, code chunk,
> abstractions... Then we have not advanced much. Of course there are
> instructions and code chunks; but the SELF model shows that you may
> obtain such kind of code with on-the-fly compilation of some higher-level
> abstractions; so that most of the time, such compiled-on-the-fly assembly
> or interpreted code or just sufficient. For the remaining 1% of time, 99%
> can be obtained by tweaking the compiler options, and the remaining 1% of
> 1% is for hand-written assembly code.
>    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....)

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

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

> > Nah.  The LLL is what glues everything together.  I'm in Bangladesh (Year 
> > 2005) using some leftover Pentium system running tunes v1.0.  I've got 
> > all my little objects humming along together (remember everything boils 
> > down to LLL) when I get an internet++ hookup.  All my little objects jump 
> > for Joy as they realize their ability to migrate onto a nearby SparcStation
> > 101010.  Alas, because we did not standardize on one LLL instruction set, 
> > they are incompatable.
> >
> > Don't let this happen to you!
>    We will standardize the LLL; only we say that, yes, this standard is
> arbitrary, and, yes, we may upgrade anytime to a new, better standards
> that we'll design before 2005; but programs using the older LLL may
> still work after proper translation/interpretation, and we'll provide the
> necessary modules for that (or if you're using some old processor which
> had a native module for the old LLL, you can use it directly).

    I like it!  =)  I guess under this scheme, we no longer have definite 
HLLs and LLLs.  It all becomes rather relative.  Would we allow for a 
SHLL (Super-high level language) to be compiled into a HLL, which is then 
compiled into a LLL, and finally converted to native code?  It could get 
inefficient, but it should be supported....

>    As we already noticed, the vocabulary frontier is having us argue when
> we agree. Who's maintaining the glossary project, already ? So our arguments
> are settled once and for all...

    Oh boy!  I can't wait until the exciting debates over glossary 
entries!  =)

> > The inter-kernel packet format is very simple.  You can build anything 
> > on top of that you like, but don't impose HLL constructs/desires on what 
> > is a simple protocol for transfering info between kernels.
>    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?

> >>>> Also note that we may also change the format, if one day we find
> >>>> ways to considerably enhance it by using uncompatible techniques.
> > 
> > Nope, I'm with Johan.  Get it right the first time.
>    How can you be sure you're right ?
> Of course, you'll do the best you can.
> But how can you be sure nobody will never ever be able to
> do even better ? You just can't. We're humans, not gods (you say it
> yourself later); we may fail. Let our *possible* failures not impair
> definitively the system. Let the system be *open*.

    Applause....  =)

> > Fat binaries encourage obesity.  I'm for a pure LLL distribution.
>    And how will you distribute the latest hyper-fast bitblt routines ?
> Or 3D game engine ? In LLL ? Let me laugh. Highly optimized code is needed
> in 1% cases; but when it's needed, you can't escape it without greatly
> reducing system performance. And recompiling with hyper optimizing options
> is sometimes not enough, or takes so much time it's not worth it.
>    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....


    Wow; quite a long message.  I hope this isn't all aimless babble.  
Just trying to understand what everyone is saying....

-Chris

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