Re: Writing an Operating System in Ada

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

On Wed, 13 Jan 2010 12:20:54 -0800 (PST), Shark8 wrote:

>>> Interact with other systems? You know, you might want to sometimes
>>> move your "persistent objects" to another machine.
>>
>> Marshaling? In terms of ADT it is assignment. Create a local object of the
>> type. Assign the remote object to it. Done.
>>
>> Provided you have the assignment defined.
> 
> What happens when the network is disrupted in the middle of an
> assignment though?

An exception

(in Ada it is Program_Error, which must be changed. This is one of Ada's
problems, which make it less suitable for designing an OO OS.
Initialization, Finalization and Assignment do not roll back)

> Is the assignment atomic?

In the same way Adjust is.

> If it's a large store of
> data is it resumable, or does having a large file on a flaky server
> doom you to never being able to retrieve the data?

If you have no CPU fan, can you run the computer? These are silly
questions. There are certain preconditions for certain services to work.
You cannot access remote objects when the network is down. So what?

>>> Did I mention that you might want to move you whole hard drive to
>>> another machine as well? :-)
>>
>> Did you try? What happens with a NTFS drive in a Linux system? Can you
>> mount it as an ext4?
> 
> Ah, here you're confusing "is a" and "has a" because the drive itself
> is NOT a file_system, but it may have one [or a part of one]. You can
> think of the file system as a format-for-the-data. So, like some
> people have done with compression/encryption and made an abstract base
> to derive from we can do the same with file-systems.

I don't see how this is related to the point. Both NTFS and ext4 are file
systems, which by no way helped to access one where only another is
supported. The same is true for any type of the objects. In order to move a
piece of memory containing an object from one system to another, the
representation of the object there must be understood.

>> This is not a question of objects or raw blocks. If the OS recognizes the
>> pluggable component, there is no problem,
> 
> Nope. The OS can detect a perfect & compatible drive and yet be
> mystified by its contents because it doesn't understand how to read
> it.

What was recognized then?

> If the drive is a dictionary, the entries are the particular files/
> directories/objects thereon, but it is pretty useless to give someone
> a dictionary in a language they can't read.

No, it only means that the object called dictionary is supported and other
objects called articles are not. The same error was made by the relational
data bases, they understand the structure of relations (relational
algebra), but do not do the elements of the tuples.

>> Note that the file system itself is built on a layer of blocks and sectors.
>> So if your argument worked, there would be no need for a file system. We
>> would still read sectors and count drive heads...
> 
> Oh please don't say that the best way to reference disk-data is by
> (sector, block) direct access... I'd prefer to have my hardware a
> little more intelligent than that, and have my CPU available for
> things other than calculating location-offsets.

It is the hardware to determine how low the abstraction can be. No lower
than 0. The upper bound does not exist. If the argument is that no
abstraction is needed, here is the device controller for you. Enjoy it.
Otherwise, one have to argue why read/write is high enough and "read text
buffer line" is too high. Obviously both are not.

>>> There is a reason why none of the pure-OO-OS-let's-do-it-correctly
>>> ever really took off.
>>
>> Yes. There are many reasons. For all there is no consistently designed
>> OOPL, Ada included.
> 
> Ada is one of the most consistently designed languages I've come
> across {LISP is another}, so if your argument is valid it should be
> more doable in such language[s] than in other languages.

Agreed.

>> Without MI, MD, tagged tasks, there is no chance to get
>> it right.
> 
> If by MI you mean multiple inheritance I think the Java/Delphi/Ada2005
> interfaces handle that pretty well.

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.

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

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