Re: Writing an Operating System in Ada

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

Dmitry A. Kazakov schrieb:
> On Mon, 18 Jan 2010 12:23:23 +0100, Georg Bauhaus wrote:
> 
>> If there is a misunderstanding, please help:
>> in a world of existing separate OSs, or of to be
>> designed OSs, would their respective persistence layers allow,
>> given the identifier of some object,
> 
> Identifier of some object = the object itself, like when you write in Ada:
> 
>     X : Integer;
> 
> X is the object and an identifier of.
>  
>> (1) calling primitive subs defined with the object's type T
> 
> Certainly.
>  
>> (2) learning about T's subs in case the object was stored
>>     by some program (defining T) not known to the caller,
> 
> No, you don't have the object then (object = identity + type + value).
> First you have to convert the type of the object and get a view or else
> another transient object of the desired type. Ada's equivalent:
> 
>    X : T'Class;
> begin
>    ... S (X) ...  -- S is a member of T'Class
> 
> You might also be able to check if X in S'Class etc.
> 
>> (3) adding subs to T to accomodate specified processing needs
>>     of another, later program? How?
> 
> By conversion of the object to another type:
> 
>    X : Integer;
>    Y : Float := Float (X); -- Now we have sin, cos etc

This conversion of a (then) persistent Integer object
to a Float object is possible because either type is known
(and can be named). The meaning of conversion from Integer
to Float is language defined, too.
That is, either object's type is known in the program storing
X as an Integer and in the program processing X as a Float,
respectively.
In particular, the second program "knows" about the possibility
of conversion of known type Integer to known type Float.

What a persistent O-O storage would have to offer is something
in addition.

In Toulouse:

  X : Private_Type_A;
begin
  OO_Store.Put(X);
end;

Then, where Identity is an identifier, or the object, or
a handle, or a filename, or ...:

Pass(Identity(X), From => Toulouse, To => Hamburg);

In Hamburg:

  Y : Private_Type_B;
begin
  OO_Store.Get(Y [, <from the identity>]);

How is Hamburg enabled to learn what Toulouse.Private_Type_A
is with the persistence layer functioning as the only source of
information about the object?  Which operations does it support?
What kind of conversions are possible, what granularity of
access to the object's innards might be needed to reify
the interface of Hamburg.Private_Type_B?

I see a hole there that needs to be filled. Indeed:

> IMO the real challenge (apart from consistent
> implementations of MI and MD) are dynamic types marshaled between the parts
> of a distributed system. I didn't think much about that, so don't expect me
> to answer how that should be solved. Probably others might have some
> insights...

I guess this challenge is what some here had hoped to learn
about. You sounded like you knew the solution :-)