Re: For the AdaOS folks

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

On Sat, 01 Jan 2005 19:31:56 -0500, Warren W. Gay VE3WWG wrote:

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

Yes, because Ada's protected objects are local and cooperative. It'd like
to see system services exposed as protected objects, with entry queues and
data fully memory protected. Same with tasks. I like OO interface to OS, no
compromises.

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

The type of the object is known. So the operations defined on it as well.

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

No, it is fundamentally different. First because there is no "save and
retrieve". The object is persistent. There is only create and delete. The
latter is automatic because of garbage collection through reference
counting. Any other operations apart from construction, copy-construction
and destruction are of no interest for the first level of abstraction. On
the second level we could define some relationships between application,
host and user objects.

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

Where is any problem? If the kernel provides persistence and your
application needs, say an integer parameter. Derive from the base
Application_Data_Type add a field, here you are.

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

Yes, Ada.Streams illustrates the idea. But problems with it are:

1. Not portable
2. No constructors/destructors
3. Oriented on sequential I/O
4. Double dispatch is hard-wired
5. Cannot deal with object dependencies (not inheritance, but references)

Basically, Ada's ADT should be extended in a way, which would allow user
types acting in a way similar to Ada.Streams.

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

Is Read_String and Write_String any better?

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

Yes it is. You have to know the names you are looking for! The first step
is of course to define some naming convention. This is a bad way, because
it is not enforced. See what happens with /etc and HKEY_LOCAL_MACHINE. So
the second step is to provide API to query that names from an application.
But that is still not good. A better way, as I said, is OO. You ask an
application: give me your settings and the result is an object of those.
The last step is to ask yourself what for? There is GNAT, an object why
cannot I talk to it directly?

> Does it really need to be more
> complicated than that?

No it need to be much more simpler!

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

Why there should be any pathnames? A name is used only to get an object
from a text map, provided that there should be one. Once you have the
object forget about its name. It has a type and so the methods to call.

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

Yes, this is the real source of our disagreement. As long as OS API are
non-OO you will fall back to bits and bytes or String and Unbounded_String,
if you want.
 
>> MD and interface inheritance from
>> concrete objects. 
> 
> If you force everything into an object metaphore, you make
> it difficult for other languages.

Did UNIX care much about Ada? We'll make them see! (:-)) OK, Visual Basic
users will have a virtual machine, it is a conventional ways to do such
things.

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

Call it service, that's no matter. I use the word OO only because it is a
known buzz word. Actually I meant ADT. The service should be a typed
object. Its entry points should have typed parameters. Type checks have to
be enforced both by the language and by the kernel. Further most of the
calls to the entry points have to be dispatching. Dispatching tables should
be memory-protected.

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

No, I cannot. The problem is that tasks and protected objects are not
tagged. As you probably saw, I do not want to build a fat sandwich
OO-interface->procedural API->OO-kernel. It clumsy, ugly, buggy and
inefficient. I want to directly talk to OS. For this its API have to
provide, say, protected objects. They need to be implemented on very
different basis, than the buil-in ones. If some of them have to be memory
protected, they might require context switches, if some of them are remote,
then queuing would require networking, data marshaling etc

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