ARGON

[Francois-Rene Rideau]

>>: Fare
>: Alaric

>> Here are some random remarks about the now updated Argon pages;
>> * "OO". Why have "objects called Entities"?
>>  One of the advantages of OO is precisely
>>  that you call anything an object...
> Purely because the finegrained things inside entities are called
> objects, and it could get confusing!
If your OS properly manages finegrained objects,
then what are these midgrain entities for?
Are you trying to build yet another multi-grain paradigm,
like UNIX with bloated processes vs low-level C structures,
or NeXTStep, BeOS, or CORBA with their mid-grain interfaced objects
vs low-level object implementations...
One of the strong points in Tunes is that at the abstract level,
there is no such arbitrary barrier between objects of different grain.
Of course, the way objects are implemented is different:
surely objects will be grouped into logical clusters;
but this could be dynamic (objects orthogonally rearranging into
different clusters), and in any case,
this shouldn't be hardwired in the abstract objects themselves,
and the casual user shouldn't have to worry about them.
The OS kernel shouldn't ever have to do that
(standard meta-libraries could).

> The programmers are used to the
> word object having a specific meaning; the entities are the furthest
> from that meaning, so I gave them the different name.
How that furthest?

>> * "Invisible persistence". You mean just "persistence".
> I'm making the point that the programmer doesn't have to do anything
> about it.
Then the standard term is "orthogonal persistence".

>>  I'm not sure about the terms "online storage" and "offline storage".
>>  I'd say fast but transient chip cache memory
>>  and slow but permanent magnetic storage memory.
> Too specific!
Ok. That was just to know whether "online storage" and "offline storage"
were standard terms for that or not.
Is the meaning obvious to all potential readers?
Else, a glossary entry is necessary...

>> * Efficiency of a portable language: it means a very high-level language,
> Not incredibly high level...
Then not efficient on all platforms.
The same bytecode just can't be efficient at the same time
on 32bit and as well as 64bit as well as 21bit architectures
(note that a byte is a wierd size for data to a 21bit architecture).
Whatever "standard word size" you choose for anything encoded in a p-code,
it will make it an inefficient p-code for architectures
were this size is too much or too little.

>> * How large is your "flat space"? 16/32/64/96/128/256/512 bit?
> That's implementation dependent!
   Then either you don't provide a distributed OS,
or you require a CPU-homogeneous network,
or your address space is not flat!

>>  Let's say 64-bit (the most probable today for a flat space,
>>  see MungiOS, Texas Persistent Store, etc).
>>  Do you mean that even embedded versions of your system on lesser computers
>>  will have to cope with that huge address size,
>>  or do you mean to discard embeddability of your OS?
> It'd work with a 16 bit address space. A style cramper, true, but not
> impossible. In practice, I think it'd be overkill for embedding,
> though; so strip off the persistence functionality and all that, and
> the resulting system (hardcoded precompiled entities in ROM with a
> communications-only kernel) would be perfect for embedding. If the
> embedded software wants to create large volumes of entities to "drag
> and drop" to other places, give all the embedded devices a storage
> manager stub that netmounts a shared hard disk drive.
Ok. Again, you'll not be using a system-wide flat space:
addressing changes from computer to computer.
You could still have some kind of system-wide flat space through
pointer-swizzling, though (see Grasshoppers, Texas Persistent Store, etc).
I'd rather make the OS purely independent of addressing sizes and formats,
by abstracting them away from the OS specification
(every OS implementation could do as it please;
standard ways would be defined in standard libraries).

>> * You say "no memory protection is necessary".
>>  You mean that over the full distributed system?
>>  How will you fight against bugs, crashes, attacks?
> The weak points are bugs in the compiler and kernel. If the compiler 
> is working OK (and it's pretty simple so it should - not like a C++ 
> compiler!), then the produced code shouldn't crash unless there's a 
> memory error or something else physical. And heck, it wouldn't be a
> problem if an implementation used the MMU. Just the kernel'd be a bit
> bigger and some things would slow down a bit.
Remember that we are talking *distributed* OS here;
physical errors are not rare in any network.
What if some node or cable somewhere crashes or is pirated?
Will that compromise the whole of your system's integrity/security?
Will that stop *all* the computations until the crash is resolved?

>> * "Cooperative multitasking" you mean the user must be trusted
>>  to explicitly yield execution?
> Nope. The compiler puts conditional yields in as it produces code.
> Real low level code - such as drivers in assembler - will have
> explicit yields. But LL code is few and far between; [...]
Ok. So you're doing the same as Tunes. Fine!
[BTW, did you read the LLL.html page carefully?]

>> * "Persistent entities"
>>  what you describe looks rather like swap.
>>  Are your swapped objects really persistent (survive a system shutdown)?
> Yes. They're written out in a portable object storage format,
> not a memory dump.
Well, they could be written as a (mostly) memory dump,
as long as the dump allows decompilation into a portable format...
Again, see the TPS...

>>  What about active objects: will they persist if I shutdown the computer?
> If you tell the OS first! Pulling the plug would cause some loss...
> Any entities without threads currently executing in them can go strait to
> persistent storage when you shut the system down. Entities with
> active threads get something like a signal saying "be gone!". If they
> don't cooperate, they can be safely forced...
That's not quite failsafe.
There exist log-based techniques
that achieve truely failsafe persistence...
See the Grasshopper papers for details...


>> * Why *byte* streams as a means of communication?
>>  this breaks any type- and semantics- based security!!!
> That's what they are /fundamentally/. Only low level code uses them as
> byte streams. To everyone else, they're object streams...
Then, you should base your OS interface on object streams,
or just objects (if your object system is rich enough to express streams),
not byte streams.
The OS "kernel" should NOT see bytestreams. Only object streams.
Bytestreams are only good for standard implementation libraries
on byte-aligned computers,
as well as for low-level modules for network management and compatibility.

>> * Loadable modules: do you have any way to check consistency and security
>>  of modules??
> Not at runtime. They must be checked statically.
MUST? What if it can't be done? (e.g. a user might later log in?).
And against WHAT are you going to check?
Do you believe that a decidable ML-like (or lesser) type system can
really express all the required consistency and security constraints?

>>  In Tunes, the user never sees the entities, but only interface to it
>>  (have you ever "seen" an memory cell?).
>>  Hence when you say "give me that entity",
>>  actually you pointed not to the low-level entity
>>  but to a particular interface to it.
> Hmmm. But when you see a spreadsheet icon floating in 3D in your
> hallucinogenic datalink and you think, "Let me see that!" surely it's
> logical to assume that you'd want to view it as a spreadsheet rather
> than see the full range of options (unless you specifically ask for
> them):
>
Sure! Because the spreadsheet icon points to
*a spreadsheet view of the object*,
not to an explicit view multiplexer of it,
less even to "it" directly.
The spreadsheet view
could still give indirect access to such multiplexer, of course,
and would of course give indirect access to "it"!

>> * Your 24bit text representation is ridiculous!
>>  you're having a gratuitously non-standard solution for representing text.
> It can be lossily converted to lesser types of text when a gateway is
> interacting with lesser software :-)
To lesser types, perhaps, but if I want a lesser type,
why force me to use your inefficient kludge?
And the problem is that most of time, I don't want a *lesser*
type, but a completely different type:
you're 24-bit format is requiring lots of extra information
I just don't care about while not supporting lots of information
I *do* care about.
Plus I know just NO COMPUTER
where 24-bit is remotely efficient to manipulate.

>>  You seriously limit the kinds of possible "character attributes"
>>  combinations to fit 256 possibilities,
> That sounds like a lot. Heck, once 640k sounded a lot. Have 32 bit
> characters, then! 65536 styles.
Still buggy.
My character attributes would include font info,
stretching info, color effect info (say for a rainbow-like colored letter),
etc, etc. And my needs will evolve. Your hardwired attributes just can't.
Or will you dynamically allocate them?
And have horrible attribute-maps much like color-maps in pictures? OUCH!
DON T HARDWIRE ANYTHING IN THE OS STOP

>> * Your don't detail your type system. I suppose a ML-like type system?
> For objects, it's multiply inherited static classes. For entities,
> it's prototyped dynamic typing.
Please detail your type system.
Do you have polymorphism? modules? Functors?
Do you have multimethods?
What in your language is statically or dynamically bound?
How do you manage covariance and contravariance
of polymorphic function types
with respect to inheritance in result and/or parameters?
Do you differentiate inheritance and subtyping?

>>  What kind of modules will you have?
> Some entities exist purely to have functionality inherited from them.
> For example, the "GUI client" entity will contain classes to
> implement a GUI interface. This is easy for the programmer, and easy
> to explain to the user ("That little icon in the Resources folder
> tells all the other little icons how to appear on screen!")
Do you really believe that inheritance is expressive enough
for everyone's needs [see the Tunes glossary entry about it]?
That still doesn't answer my question.
What kind of module system will you have, if any?

>>  Will ARGOT be reflective?
>>  What impact on the type system will that have?
>
> Exactly which definition of reflective are we talking about here?
> I've heard two: that of systems like FORTH that described themselves
> in terms of themselves, and those like CLOS that use metaobject
> protocols. Well, ARGON proper is more like the latter, and ARGOT is
> more like the former...
Both are the same: a metaobject protocol is the way through
which a language can describe itself.
And that *does* have strong impacts on the type system.
Lisp and Scheme solved that by having
a trivial strong type system with a one huge union type.
Napier did it by having some kind of source-string based reflectivity,
instead of a fine-grained syntax-tree based one.
BETA seems to do things ok, by supporting full syntax trees,
but I'm not sure exactly how they do things...

>> * There is no semantical between your "DO" and your "SEQ"!
                 ^^^^^^^^^^
> DO need not be executed sequentially. Consider the example of putting
> three numbers down a stream. If the order didn't matter, a DO would
> do - for example, if they're random numbers. If the order did matter,
> use SEQ, because with a DO, the compiler may reorder things to make
> execution faster (keep values in registers longer). PAR would do; but
> it implies that the three numbers would be inserted simultaneously,
> it's only an implementation detail that resource collisions are
> detected and resolved automatically. PAR would be confusing, and
> would lead the compiler to try to parallelise when it's not
> necessary. SEQ is needed to say, "Look! You'd better get these in
> /order/!". DO is what programmers would normally use; PAR and SEQ are
> for extremes.
Nope. You're confusing semantics and implementation details.
That's definitely WRONG.
If your code is such that order doesn't matter,
then SEQ and PAR are equivalent to it,
and you shouldn't care about that,
because the compiler should be able to choose
whatever combination fits most the available runtime resources.
If your code is such that order does matter,
then it's your choice whether you go PAR or SEQ or whatever,
because the resulting program's semantics will be different.
Note that PAR is *never* "simultaneous".
Simultaneous just does have no meaning on parallel architectures.
"In unspecified order" does have a meaning.
   What's the *semantics* for your DO?
That things are done "as if" done by SEQ (resp. by PAR)?
Then it is only SEQ (resp. PAR) with a stupid compiler annotation
hardwired in the language.
Surely compilation tactics should be given independently from
a program's semantics.

>> Finally, what in your project requires that this be implemented as the OS?
> Nothing!
Well, then first do try to prove your concepts on top of an existing OS!

>> Couldn't you just build it over Linux?
> Yup... but for the reasons for and against that, see your own OTOP
> subproject :-)
Whose conclusion is FOR, in the first time...

[difficulties downloading VSTa]
Use a mirror, then (sunsite.doc.ic.ac.uk near you does mirror it)!
Or have a background download done at your ISP's
then just download from ISP to home!

>> Are [existing OS *kernels] inadapted to what you want in any sense???
> Just a little overkillish in places.
> I'd be inclined to start with
> something like VSTa rather than start from scratch, though.
You could also start from L3, L4, the Flux OS Kit, and/or whatever.
See the Tunes OS Review page and pointed pages for that...

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"