Re: Writing an Operating System in Ada

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 14 Jan 2010 10:01:48 -0800 (PST), Shark8 wrote:

>>>> There shall be no interfaces at all. Ada 95 had everything needed, i.e.
>>>> abstract types. Introducing interfaces in Ada 2005 was a huge mistake.
>>
>>> 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. (:-))

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

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

(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)

>> Ada has type declarations, public and private. Everything visible related to the type is the contract of.
>> Period.
> 
> I agree that everything visible is the [ultimate] contract of the
> type. However I don't see why having an interface is any different
> than having as an inheritance-base a fully abstract object. Can you
> explain how you see it as such then?

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! (:-))

>> 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);
>>
>> That is a mess and a maintenance disaster.
> 
> That sounds like a bad idea, true. But isn't it also an exercise in
> misdesign to throw in "just in case we need it" haphazardly?

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;

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.

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

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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de