ARGON

[Alaric B. Williams]

On 17 Dec 96 at 9:48, Francois-Rene Rideau wrote:

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

> * "Invisible persistence". You mean just "persistence".

I'm making the point that the programmer doesn't have to do anything 
about it.

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

> * You don't give any evidence how your language is more (or less)
>  crashproofing than Java (so you do think Java is crashproofing? hahahahaha!)

A bit brief there, I guess. I'll go into some more detail Next Time 
(tm).

> * Clearance codes: will you hardwire that in your "kernel"?

The clearances are part of the storage manager, which is a "kernel 
component", but it's not quite hardwired. OTOH, different people 
using different storage managers could lead to compatability 
problems.

> * Efficiency of a portable language: it means a very high-level language,

Not incredibly high level... 

>  hence more time needed to compile. How do you intend to achieve that
>  with a bytecode???

...the parts of it that the compiler need worry about are merely the 
special case classes, ie the integers, or closures. The rest is done 
in terms of that.

> * How large is your "flat space"? 16/32/64/96/128/256/512 bit?

That's implementation dependent!

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

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

> * "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; with the drivers 
for DMA, IO, and IRQs written in assembler, the rest is high level. 
Low level modules could use a 'pragma' to lock regions of code by not 
putting in yields - and dare I say, even disable interrupts!

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

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

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

> * Loadable modules: do you have any way to check consistency and security
>  of modules??

Not at runtime. They must be checked statically. 

> * <<One Interface can be marked as a default. This interface is the one
>    used when the user simply says, "Give me that entity">>

>  I disagree. This uselessly makes the intrinsic object system
>  more complicated.
>  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):

Spreadsheet
Security domain
User of storage
...


> * 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 :-)

Conversion routines:

CHAR: ASCII  (returning an unsigned byte)
CHAR: UNICODE (returning an unsigned doublebyte)
CHAR: EBCDIC (etc...)

and appropriate character constructors from other character sets.

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

>  you build yet another non-standard UNICODE.
>  You allow only 4096 characters at a time,
>  which makes chinese support altogether useless.

Chinese etc. would cover several categories! I'm using 16 bits for a 
character, so if Unicode can fit it, I can. And unlike Unicode, I 
don't see a good reason to be bitwise ASCII-compatible when I can be 
ASCII compatible with a lookup table/function, and use a more 
convenient internal format.

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

>  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!")

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

> * 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.
 
> Finally, what in your project requires that this be implemented as the OS?

Nothing!

> Couldn't you just build it over Linux?

Yup... but for the reasons for and against that, see your own OTOP 
subproject :-)

One point to be made here is that it's possible for UNIX or 
Windows apps to use an ARGON communications library and coexist with 
ARGON machines on a network. They'll be able to present and use 
entities, but creating those entities will be more backbreaking than 
making them in ARGON by prototyping!

> Let's say you need to rebuild a full programming environment.
> Why not use an existing micro-kernel like VSTa, Mach,
> or an existing OS kernel, like Linux or the HURD?

They'd try to do too much. A real micromicrokernel would be fine, 
though. QNX would be a natural (although expensive and monopolised) 
underlying platform. VSTa probably would, too, only I've never 
managed to download it (it goes slow then the connection drops :-(

> Are they 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.
 
> == 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/"

ABW
--
Governments are merely protection rackets with good images.

Alaric B. Williams Internet : alaric@abwillms.demon.co.uk
http://www.abwillms.demon.co.uk/