Re: For the AdaOS folks

["Warren W. Gay VE3WWG" <ve3wwg@NoSpam.cogeco.ca>]

Dmitry A. Kazakov wrote:
> On Fri, 31 Dec 2004 11:24:40 -0500, Warren W. Gay VE3WWG wrote:
>>Dmitry A. Kazakov wrote:
>>>On Fri, 31 Dec 2004 06:30:51 -0500, Warren W. Gay VE3WWG wrote:
>>All of the infrastructure that you talk about is built outside of
>>the mk. The mk's purpose is to provide the basic needs for an OS, but
>>_not_ be the OS itself. In fact, using a mk approach, application and
>>OS modules conceptually run beside each other, perhaps only differing
>>in the privileges they have (ports that they have rights to).
> 
> I agree in principle, but disagree in details, in what are these basic
> needs. I think that a kind of "protected object" should be provided already
> by the kernel as a building block.

Ok, but if your Ada RTL provides it, do you really care that
much whether it is in or out of the OS?

> When we know little and just start
> to explore a new field of computing, we always start with 1. Then we gather
> knowledge, get frustrated with "flexibility" of making errors and switch 2.

This _assumes_ flexibility = errors. I don't believe this to
be generally true; but I'll agree that it _can_ be.

> That happens when we already know how-to. But having reached the stage 2,
> we find it possible to do things we could not approach before and so open a
> new field. Then again first 1, etc. ]

Perhaps, but it is not always good or necessary to straight-jacket
APIs. It should only be applied to curtail abuse, without limiting
the programming capability.

> The point is, it seems that with installation/properties/profile issue we
> have reached the stage when we could start to think about 2.

Sure, we can think about it, but IMO I don't think anyone has
gone beyond the registry in proposed solutions yet.  You say
"OO will do it better", but haven't supported the "why" it will.
You avoid that by not talking about "how". If I avoid answering
the "how", I could propose a lot of "better" ways.

>>What does "object persistence" have more than a "set of values"? How
>>is an "object container" any different than a directory/subdirectories
>>containing "values"?
> 
> The difference is that the above is untyped or weakly typed. An object is
> not just a value but also the methods to apply. This firstly would prevent
> abuses, and secondly, we could define somewhere an abstract interface to be
> implemented and so enforce proper behavior.

But a persistent object is nothing more than a blob of data
recorded in a file (or something acting as a container). The
fact that it might have methods makes no real difference. Who provides
the methods?  If you have to provide them, then you make matters
worse (we're back to everybody writing their own way to save
and retrieve data in their own way). If you don't, then this
cannot possibly anticipate your needs, unless you use something
like Ada stream I/O. But you don't want to commit to "how" this
is done, so it remains an unsubstantiated claim, and we cannot
progress in that discussion ;-)

>>But you have not proposed any solution.  You keep saying that
>>"I don't want to be responsible", but there is nobody/nothing
>>left to fill that void.
> 
> In OO the object is responsible to provide an implementation. 

But who writes the object? The kernel writer can't. How is he
going to anticipate all of your configuration needs for your
application and mine?

You already have Ada.Streams, but so what. I don't see that as
an improvement for this purpose.

> A minimal
> kernel should give an ability to define some system object. A pair levels
> above there should be defined an abstract interface of application
> persistent data. Each application that possesses such data have to
> implement that interface etc.

This still doesn't say "how" it is better, or "how" it will
be done. Without saying "how", you could promise the moon.

>>Not everything manifests itself as a diamond (obviously). If a
>>hierarchy or "node network" doesn't satisfy your needs, then
>>I'd like to hear just what other structure can.  You can't
>>just close your eyes and say "just make it happen". We don't
>>enjoy that luxury! 8->
> 
> Node network, relational data base, tree-like structure with links, all
> that are just implementations of an abstract interface of what a repository
> should provide. 

So what? Eventually everyone has to "choose" something.

 > We will go no further if we will try to put the cart before
> the horse. First we must define the interface, its implementation is a
> minor problem.

As part of any abstract discussion, you do have to eventually
consider the practical aspect of "how" it will be done. Otherwise
people can make all kinds of promises that can't be kept.

>>So you don't want an API, and yet you want it to happen somehow.
> 
> No, I do not want to see Read_Block and Write_Block in API. 

Sure, but who was proposing that?

> Writing an Ada
> program, I do not see LDA, STR, MOV. They are still there, somewhere
> beneath in the Underwolrd, but I don't care. 

Of course. But when you want to know where GNAT is installed, it
is very easy in Windows to lookup a registry key and get the
pathname for it. If I want to know where APQ should be installed
as an Ada binding, I can do another registry query and get the
top level GNAT directory for bindings.

Is that so complicated?  Does it really need to be more
complicated than that?

>>Somehow,
>>some piece of software/hardware/system is supposed to know what pieces
>>of information are configurable elements, know how to organize it,
>>know how to identify it and share it in a safe way with other processes
>>and users on the same system/network?
> 
> The answer is ADT. As long these pieces are just bytes, there will be
> nothing much better than Windows/UNIX. It is time to make a technological
> leap.

You keep saying "just bytes". Even the windows registry is better than
that, and you know that. Call it "weak typing" if you like, but you
can't say it is a bad idea because it _can_ be worse. Discuss the idea
on the merits of what it _can_ be.

How strongly typed do you make your pathnames in your programs? Do you
really define a different string type for different pathnames and
file names? Most people would find a String or Unbounded_String
acceptable.

...
> Purely theoretically it could be C, but
> practically the result will be null. Then even Ada is still unsuitable for
> this, as long as there is no great type unification, which would allow to
> develop user-defined protected objects, tasks, access types etc.
 > This should become the basic gear to build OS types.

Yes of course - ie. it must support the Ada RTL, at least.

 > I also cannot imagine any
> decent OO design of OS without MI, 

But the O/S has nothing to do with MI, unless it wants to sport
an OO interface (which IMHO is unnecessary, at least for many
APIs).

> MD and interface inheritance from
> concrete objects. 

If you force everything into an object metaphore, you make
it difficult for other languages. Frankly, for the services
that you get from an O/S, I don't see much point in putting
an OO face on it.

If you look around, you'll see a number of people are getting
less fanatical about objects, and in some cases are talking
"services" instead. And that is largely what the operating system
provides. But if you say you must have OO interfaces, then
the Ada RTL is there to let you model any way you see it.
You could even write packages for this, or if you don't like
the one you have write alternatives.

> Alas there is no visible efforts in these directions.

Practical ideas tend to get implemented (and thus become
quite visible). Impractical onces either remain dreams or
wait for the right opportunity. Either or both could apply,
depending upon your expectations ;-)
--
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg