Re: Writing an Operating System in Ada

[Shark8 <onewingedshark@gmail.com>]

> >> 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? Furthermore, what sort of system would you use to
solve the diamond problem?

Given two types, say a Clothing.Button and a UI.Button why shouldn't a
clothing manufacturer be able to have a hybrid object implementing
both contracts that would allow a customer to [for example] design the
button they want on their clothing. (The specialized buttons for
military dress-uniforms, say.)

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

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

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

> > I think we have a failure-to-communicate here. I agree that relational
> > algebra [blindly] works on tuples w/o knowing about the contents...
> > that is in a sort of abstract fashion.
> >
> > If we use metaphor/allegory for the data-system [hard-drive, FS, data]
> > would you agree that it could be likened to the following?
> > The hard-drive is like unto a library containing books.
> > The books of that library are like unto the data/files.
> > The FS is like unto the indexing system (alphabetically by title,
> > alphabetically by author, dewy-decimal, etc) coupled with the
> > methodology for storing the 'books' (are they in boxes, on shelves, in
> > a pile, etc).
>
> > Can we both agree on this?
>
> 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"? It would make things easier from the migration-to
standpoint. True we wold have to have a method of determining the type
of some file in the absence of type-data storage, but we would have to
have such in any communication with some system which didn't use
types. (*cough* UNIX *cough*)

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

This also brings to mind: it could be _very_ useful if libraries &
programs were objects-in-the-abstract (like a task type perhaps).

> >>> If MD is multiple dispatch then we're talking about something that
> >>> simply explodes combinatorically-speaking: Say we have a multi-
> >>> dispatch procedure with two dispatching parameters [Letter and
> >>> Number], ok? Now, if we have two versions of each of those in the
> >>> classes we get something like:
> >>> (A,1)
> >>> (A,2)
> >>> (B,1)
> >>> (B,2)
>
> >> Yes. Let you have printer devices and shapes. This is a classical example
> >> of MD. Yes, it explodes. That is the law of nature. There is nothing to do
> >> about it, with MD support or without it, you have these combinations, you
> >> have to handle them. MD does not solve this, it merely provides an
> >> infrastructure helping you to solve this. No more, no less.
>
> > Ah, I think I was confusing the problem with that infrastructure
> > then...
>
> > But that does remind me, I was thinking it would be good to have
> > PostScript as the display for the OS, unifying the visual display that
> > way it would eliminate the need for printer drivers (assuming they're
> > postscript printers) as well as providing a true WYSIWYG for print-
> > preview (MS's print preview can be a bit... inaccurate), right?
>
> Right, but in an OO system you would barely need PostScript. I doubt
> anybody would like to program in PostScript, so what is left? Poor as a
> data carrier, unusable for humans. Doesn't it remind something? XML? (:-))

Exactly. For visual data to the screen and printer it would make a
good unified format. We don't have to actually have people programming
in PostScript, just have [UI] objects know how to output it and
[display] objects know how to render it... which is EXACTLY the class
a PostScript printer falls into.