Criticism ... synthesis?

[Francois-Rene Rideau]

> Can somebody _please_ forward me the communications from 14 - 16 
> December,
> as I was in transit from NZ to RSA and missed all, including 
> responses to
> my comm of 14 December (am).
Err, the complete tunes archive is on the usual moose ftp site:
frmap711.mathp7.jussieu.fr:pub/scratch/rideau/moose/TUNES/mail*/tunes*
If you can't ftp, I'll bounce all that to you...


> 1. You use "monolithic" in criticism of an idea that is 
> straightforward, and instead postulate a more complex system!
   Computing *is* complex anyway. I propose that the system directly
accepts complexity, instead of requiring other systems to be built
on top of it to handle that (which would make our OS useless).

> 2. "hugeware" ?
> My initial statement (and it appears in Mike's compilation of our 
> goals)
> was that the core code should be +- 20 lines (with everything stemming
> from this). Yours is obviously a completely new interpretation of the
> word "huge"!
   Mike was suggesting that builtin in our OS "kernel" would be a 3-D
engine, BitBlt routines, et al ! And that any asm things possibly needed
should be inside our system.

> 3. "centralised". This is again unfair. Sharing common characteristics
> is not the same as being centralised. 
   And what does a 20 lines core code mean anyway ? Does it mean that
those 20 lines would be ever called again ? Why have such thing ? Why
being always required to call some centralized code at all ? Why not
inline possible code to call other objects directly ? Why have some
constant overhead however simple the communicating objects are ?
This would mean a limit to object grain below which having it systemwise
it a loss; so that peoplee would be forced to build systems over ours to
manage small objects, and have to build complex interfaces to allow
combining their possibly small objects to system objects !!!
   That's the flaw of microkernel. You don't remove centralization by
reducing the size of the kernel, but by eliminating the kernel.
If you want microkernels, go VSTa, Mach, or Chorus !!!


> 4. "unsecure". I cannot see why security should be better in your 
> system (with what seem to be great big wodges of uncheckable code) than in 
> Mike's.
   Because security is an infinitely complex thing. Code is complex, and
conditions to have it work correctly is much more complex than a question
of having a bit set in some capability flags. You can't centralize security;
every object is responsible for its behavior, and may require objects that
want to connect to it to fulfill some arbitrary conditions. In my system,
objects are free, and self-responsible; whereas in a centralized system, the
kernel is responsible for everything. The VSTa experience shows that security
becomes a mess, and that "user"-level security is needed anyway, so that
the kernel stuff is only yet another useless obstacle to free programming.


> In my mind, the _whole LLL idea_ is to have a symbolic low level 
> language that
> is independent of the machine. A sort of "C" without the fuckups, 
> redundancies
> and unnecessarily high-level constructs. Sure we can upgrade the LLL, 
> but
> this should never, ever, mean incompatabilities with prior code.
Then your LLL is not so Low-level :) and that's the kind of thing I'm for.



> >   Why ? No one forces you to forget older modules, or to translate 
> them.
> >Remember we have a distributed system. There might be a "good virus" 
> that
> >would spread and translate everything to the new standard, etc.
> 
> And you call this 
> secure???????????????????????????????????????????????????
> You are introducing the potential (once we have worldwide "Joy") to 
> destroy
> the whole of civilisation with a single bad virus masquerading as a 
> good
> one. Your argument here is the best one yet _AGAINST_ your system.
   A "virus" is something everybody is willing to use; and the only way
to achieve that is having the object perfectly secure for all:
because it comes with a correction proof and/or has some unfakable
signature. It will be no more (or less) virus than latest versions of
MS-DOS, Windows or MacOS spreading, but instead would spread automatically
(unless you disable the trust toward this signature for your computer).
   Actually, the spreading mechanism is that of requiring a module. If
you want to control it, you can. And again this is no less secure than
manually upgrading software by ftp (unless you disable all the security
checks for imported modules).


> Both wrong, both right. Very infrequently, one may need to EXTEND the 
> LLL.
> I cannot see any point in ever completely rewriting it - might as well
> junk the whole system at that stage, and begin again (which is what 
> you
> would effectively be doing, anyway).
Nope. You can very well keep the HLL and change the LLL, so the system
is the same userwise, and yet upgraded. As Jch stated, LLL's may get
specialized toward some new kind of hardware or high-level software to
get more efficient compilation. For example, if we have a RISC-like
LLL, and computer architectures go toward MISC, then the LLL might have
to be changed completely !


> >   I'm for a free world. Freedom allows selection of the fittest. By 
> some
> >authoritarian way, you may force some good thing to happen, but you 
> break
> >the dynamics, and won't be able to evolve.
> 
> FREEDOM DOESN'T IMPLY TOTAL ANARCHY.

Not at all. But we won't provide some compulsory centralized state, but
only optional *standard* services that people may freely use, or not use
if they find better service providers.



>>   Objects are allocated in a GC-able heap or outside it.
> 
> Are you sure you need this? Why not (for example) have each object 
> handle its own GC. (ie be given resources, and dispose of them as it
> sees fit, returning all to pristine state on exit)?
   GC is a must in persistent system. And in a multi-* system, you
can't statically decide when an object is no longer needed. Requiring
objects to handle there own GC is monstruous as for code size. This
should be *possible*, but surely not *required*. Really, the LLL should
include some GC mechanism (that perhaps could be disabled). You can't
build any dynamic system without GC.


>  Let's agree on data types and then discuss implementation.
Yep.
See previous posts from frmap...



>>> It's not aceptable to have the computer say "I can't understand Fred 
>>> because I don't have the proper communications drivers"
>> Just load them. You can have them together with Fred's stuff.
> 
> No, hang on a bit. I'm running on a 486. Fred has a 68030. Jane is 
> tinkering with a Z80 just for the hell of it. Fred has a brilliant new
> program he has just written. It uses a variety of low level drivers, 
> that
> work well on his system. Jane and I still need drivers for our system.
> Are these drivers:
>     A. Local to us?
>     B. Written in a common low-level (kernel?) that all systems
>         share?
> Well? (Or must, gods forbid, Fred keep a copy for all possible 
> systems???)
The local system requires a driver that will work for it, and selects
the best one for that: if it can find native code for the local machine,
this it will take; else it will try find a LLL version, etc. Conventions
are that any portable code should include at least a LLL version. But a
8086 may well prefer translating Z80 code than LLL code...


> >Ok, so for "Object", say: "a unifying concept that encompasses just 
> any
> >computing abstraction. Objects are furtherly managed according to 
> their
> >useful properties, and not according to some unadapted arbitrary
> >distinctions".
> 
> This is mind-numbingly vague. Whatever happended to inheritance,
> encapsulation and polymorphism??
If they are useful, they'll be encompassed. But these are HLL abstractions...
At LLL, objects are connected or not, and need a meta-protocol to connect
them. This meta-protocol may or may not take into account such abstractions.




> Part 3. A proposal.
> -------------------
> Rather than arguing in circles forever, let's:-
> 
> 
> 1. DEFINE "DATA TYPES"
>     a. constants
>     b. variables
>     c. numbers
>     d. blocks
>     e. pointers (to blocks)
>     f. verbs
>     g. interpretable combinations of a..f. ("friends")
>     h. objects
>     [Please feel free to add or subtract, constructive
>         criticism is welcome]
   I don't see it that way at all !
   There are basically numbers and characters of various length (atoms).
Then, there are pointer/references; there may be a way to ensure that
pointed things remain constants (which may be useful for the GC to know).
Blocks are implemented in a standard library, and the LLL specifies
only manipulating pointers to blocks, and accessing blocks through
standard verbs. Verbs are also some LLL concept, and standard verbs
exist to combine them (your "friends", though I see no link between the
name and the concept). Objects are accessed through verbs.
   This LLL concept seems very FORTH-like, but that it was not yet
decided if a stack was to be used, and that we differentiated atoms
from pointers (to allow GC).


> 2. DEFINE OUR LLL
>     a. symbolic registers, including "pointer registers"
>     b. necessary flags
>     c. Suggested primitives:
>         ADD SUB MUL DIV SHR SHL ROL ROR OR XOR AND NOT NEG
>         TEST_UNDER_MASK
>         REQUEST / FREE "memory" block (in broadest sense)
>         POINTER creation
>         GET / PUT
>         PUSH / POP
>         CONDITIONAL_BRANCH (or skip)
>         "CALL" / RETURN


All the following are not needed as *primitives*.
Have standard verbs for that, using implementation-dependant
primitives. Perhaps everything should be done this way (even the
previous): there are reserved codes for the "primitive" verbs,
that may (or may not) get inlined when the LLL is loaded.

>         FORK / JOIN
>         HOW_LONG
>         (relevant graphic_display primitives)
>         (relevant visual_perceptive primitives)
>         (relevant speech primitives)
>         (relevant sound_generation primitives)
>         (relevant hearing_perceptive primitives)
>         (? relevant spatial_descriptive&perceptual primitives)
>         GET_FROM_STREAM / WRITE_TO_STREAM
>         ? DO_CRC
>         ? COMPRESS / DECOMPRESS ??!!
>         ? RANDOM number generation
>         ? INSERT into block
>         ? EXCISE from block
>         ? SEARCH / SORT
>     etc....
>     [Please feel free to add or ***subtract***, constructive
>         criticism is welcome]

It reminds me the time (some several years ago) when I made such
enumerations...