Re: Writing an Operating System in Ada

[Shark8 <onewingedshark@gmail.com>]

> >>> Why do you say that?
>
> >> Because there should be a honest MI and no interfaces.
>
> > But Ada doesn't support honest MI. How do you propose to work-around/
> > implement that?
>
> By changing the language standard, of course. (:-))

Ah, but this brings up a question: HOW do we change it?

> > Furthermore, what sort of system would you use to
> > solve the diamond problem?
>
> I don't need to solve it. It is firstly not a problem and secondly it
> perfectly exists in interfaces:
>
>    type A is interface;
>    procedure F (X : A) is abstract;
>    type B is interface and A;
>    type C is interface and A;
>    type D is interface and B and C;
>
> It also does in packages (with/use) and many other cases.

But isn't B.F exactly equal to C.F in that we're using an inherited
procedure/function? The diamond problem is about components named the
same that have different types... because interfaces ARE abstract
objects (with the further restriction that they are denied fields)
they don't suffer from the diamond problem. {That is the footprint of
Procedure Foo is EXACTLY the same in all three, they are all the
same.}

> >> You do not need explicitly named contracts in a language like Ada. The
> >> contract of a type is the type itself.
>
> > Agreed, you could define all the operations of both inherited types,
> > have them as mix-in components, and handle things that way. That
> > method however excludes the option of saying something like "if Hybrid
> > in Clothing.Button" and "if hybrid in UI.Button" at the same time (you
> > could inherit from one and then be able to use one of the above,
> > true).
>
> Use T'Class with membership test S in T'Class.

You're right I forgot the 'Class. But the problem still stands with it
rewritten as such.

> (It is a bit sloppy that Ada uses "in" both for S in T and for S in
> T'Class. In mathematics membership and subset are two distinct relations)

True. But if we're talking about an OO hierarchy then a derived-member
of some class IS a superset of that class; and also as things fall
into a nice hiearchy, we see that these classes themselves are sets.

> Why do I need interface? What does it add to
>
>    type T is abstract private;
>
> existed in Ada 95. (Answer: it adds a new reserved word! (:-))

LOL

> >> Rather than *in advance* trying to declare all possible interfaces. It is
> >> awful and leads to an explosion of meaningless declarations like:
>
> >>    type T_Interface is interface ... ; -- Just in case we would need it!
> >>    procedure Foo (X : T_Interface) is abstract;
> >>    type T is new T_Interface with ...; -- No we starting to work
> >>    overriding procedure Foo (X : T);
>
>
> If you have a large system, you never know in advance. The code like above
> is from a real project. We are probably in a minority who actively deploy
> Ada 2005 features. We have a lot of interfaces and more we have them, less
> we enjoy them. He have approximately 20-30% of utterly meaningless cut and
> pasted code because of lack of MI. As a trivial example consider:
>
>    type Read_File is limited interface;
>    procedure Read (File : in out Read_File; ...) is abstract;
>
>    type Write_File is limited interface;
>    procedure Write (File : in out Write_File; ...) is abstract;
>
>    type Read_Write_File is limited interface and Read_File and Write_File;

I think it points to a bad design. IMO, I think something like this
would be in order:

Type Abstract_File is limited interface;
-- All abstractable file operations go here.
Function Readable( File : in Abstract_File ) return Boolean is
Abstract;
Function Writable( File : in Abstract_File ) return Boolean is
Abstract;
Procedure Read ( File : in Abstract_File; Stream :
Stream_Class'Class ) is Abstract;
Procedure Write( File : in Abstract_File; Stream :
Stream_Class'Class ) is Abstract;
-- And so forth.

> How consider how would you implement these somewhere at the bottom of a
> hierarchy of concrete file types. Add there some other inheritance axis
> like handles to files, different contents, different devices (here you will
> badly need MD, but that is another story). Then observe how code
> duplication propagates from the bottom up all the inheritance levels
> multiplying itself at each. This is customary fought using generics which
> crown the mess.
>
> >> Sure. Translated to OO: FS is a specialized persistent container library.
>
> > Excellent. Why then would it be a bad idea to support FS-in-the-
> > abstract considering that currently [virtually] everyone's data is in
> > one instance or another of this "specialized persistent container
> > library"?
>
> Surely it is.

That doesn't answer the WHY question.

> > It would make things easier from the migration-to
> > standpoint.
>
> It would not, because the difference is not in a tree-like structure of
> named elements, but in the types of those elements.

Um, are you forgetting the librarian/library/book metaphor from
earlier? The FILE is like the book, it's type is a property of the
abstract-type "book," the Library is the physical drive where you go
to get said book, the librarian is the one who knows how to traverse
the organization/disorganization within the library is the FS. (Not
all FSes are Hierarchical, think of them as some ADT holding some
File'Class objects.)

> >>>>>> Without MI, MD, tagged tasks, there is no chance to get
> >>>>>> it right.
>
> > Couldn't we emulate tagged tasks [to some degree] by having a "Tag"
> > entry with an output parameter giving the tag?
>
> You have to be able to derive from a task, that is what active objects are.
> BTW, you already can do this in Ada 2005. It has task interfaces, but this
> inheritance is limited to have the depth of 1.

I remember reading that now... but is an inheritance level of 1 good
enough? Possibly if we were to abstract things in the correct manner.
If the inheritance level is one, is it also legal to have task types
Abstract_Program and Abstract_something which are both implemented in
a single class/case? {It would have the requisite depth of 1...}