Writing an Operating System in Ada

Writing an Operating System in Ada

[Shark8]

I was wondering if there would be any interest in coding up an OS in
Ada. I don't mean taking an existing codebase and rewriting/converting
it to Ada, but implementing it from the ground up. It's been a bit of
a "for later" project for me to write an OS, although I did begin to
write one in Turbo Pascal which got to the point of being able to
recognize user-commands & (based on those commands) change the screen
resolution. {And all using less than ten lines of inline assembly!}

As time went on the project went on the back-burner and "later" never
really came around, but in that meantime I was finishing up my degree
in CS and came across Ada in my senior-level programming languages
class. The design of Ada impressed me a lot and so I got myself
Barnes's Ada 2005 book and started teaching myself. (So, in reality
I'm pretty new to Ada, but I do come from a Pascal background and like
the idea of having my compiler check things for correctness.)

Anyway, I was wondering if anybody here would be interested in such a
project.

Re: Writing an Operating System in Ada

[Leslie]

Shark8 wrote:

> I was wondering if there would be any interest in coding up an
> OS in Ada. I don't mean taking an existing codebase and
> rewriting/converting it to Ada, but implementing it from the
> ground up. It's been a bit of a "for later" project for me to
> write an OS, although I did begin to write one in Turbo Pascal
> which got to the point of being able to recognize user-commands
> & (based on those commands) change the screen resolution. {And
> all using less than ten lines of inline assembly!}
> 
> As time went on the project went on the back-burner and "later"
> never really came around, but in that meantime I was finishing
> up my degree in CS and came across Ada in my senior-level
> programming languages class. The design of Ada impressed me a
> lot and so I got myself Barnes's Ada 2005 book and started
> teaching myself. (So, in reality I'm pretty new to Ada, but I
> do come from a Pascal background and like the idea of having my
> compiler check things for correctness.)
> 
> Anyway, I was wondering if anybody here would be interested in
> such a project.
        Interestingly, I was just thinking last week while reading John
Barnes' /Programming in Ada 2005/ that Ada would be a fine
language to user for writing an OS.  I'm not yet proficient in
Ada, but would be interested in contributing what I can.

Leslie

Re: Writing an Operating System in Ada

[Shark8]

Excellent. Good to know I'm not completely alone.

I busted out my sourceforge account and started a project for it.
[ https://sourceforge.net/projects/admiral-os/ ]
I chose the name Admiral as a bit of a nod to the old Commodore. {Side
note: it's AMAZING what they did with 64 or 128 KB & 1 to 2 MHz of 8-
bit CPU goodness!}

Re: Writing an Operating System in Ada

[Ludovic Brenta]

Shark8 wrote on comp.lang.ada:
> Excellent. Good to know I'm not completely alone.
>
> I busted out my sourceforge account and started a project for it.
> [https://sourceforge.net/projects/admiral-os/]
> I chose the name Admiral as a bit of a nod to the old Commodore. {Side
> note: it's AMAZING what they did with 64 or 128 KB & 1 to 2 MHz of 8-
> bit CPU goodness!}

Have a look at http://www.lovelace.fr

This project is dormant at the moment but you can already check it
out.

--
Ludovic Brenta.

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Mon, 11 Jan 2010 17:13:55 -0800 (PST), Shark8 wrote:

> Anyway, I was wondering if anybody here would be interested in such a
> project.

If that will be a really new OS (not a UNIX clone), OO, portable,
distributed etc, for interesting platforms like this:

http://blog.makezine.com/archive/2009/08/scalable_open_source_computing_plat.html

why not?

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

Re: Writing an Operating System in Ada

[jonathan]

On Jan 12, 8:36 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:

> Have a look athttp://www.lovelace.fr
>
> This project is dormant at the moment but you can already check it
> out.

MaRTe OS is another thing worth looking at.
I notice that MaRTe OS is alive and well.  The latest news
from the web site:

  19/Aug/2009
  New release of MaRTE OS : Adapted to GNAT-GPL-2009

(In other words you have to use the GNAT-GPL-2009 Ada compiler
to compile the latest version.)

A good starting point might be to boot and explore Marte OS,
and then decide which direction interests you.

In any case, the source code should be interesting:

   http://marte.unican.es/

Jonathan

Re: Writing an Operating System in Ada

[Colin Paul Gloster]

On Mon, 11 Jan 2010, Leslie wrote:

|-----------------------------------------------------------------------|
|"Shark8 wrote:                                                         |
|                                                                       |
|> I was wondering if there would be any interest in coding up an       |
|> OS in Ada. I don't mean taking an existing codebase and              |
|> rewriting/converting it to Ada, but implementing it from the         |
|> ground up. It's been a bit of a "for later" project for me to        |
|> write an OS, although I did begin to write one in Turbo Pascal       |
|> which got to the point of being able to recognize user-commands      |
|> & (based on those commands) change the screen resolution. {And       |
|> all using less than ten lines of inline assembly!}                   |
|>                                                                      |
|> As time went on the project went on the back-burner and "later"      |
|> never really came around, but in that meantime I was finishing       |
|> up my degree in CS and came across Ada in my senior-level            |
|> programming languages class. The design of Ada impressed me a        |
|> lot and so I got myself Barnes's Ada 2005 book and started           |
|> teaching myself. (So, in reality I'm pretty new to Ada, but I        |
|> do come from a Pascal background and like the idea of having my      |
|> compiler check things for correctness.)                              |
|>                                                                      |
|> Anyway, I was wondering if anybody here would be interested in       |
|> such a project.                                                      |
|        Interestingly, I was just thinking last week while reading John|
|Barnes' /Programming in Ada 2005/ that Ada would be a fine             |
|language to user for writing an OS.  I'm not yet proficient in         |
|Ada, but would be interested in contributing what I can.               |
|                                                                       |
|Leslie"                                                                |
|-----------------------------------------------------------------------|

If the two of you are willing to implement an operating system in Ada
then proceed and succeed! I wish you well. However, every few months
or years hobbyists' projects for volunteers to develop an operating
system in Ada not aimed at embedded targets have been proposed on this
newsgroup without ever amounting to anything.

Regards,
Colin Paul Gloster

Re: Writing an Operating System in Ada

[Shark8]

> If the two of you are willing to implement an operating system in Ada
> then proceed and succeed! I wish you well.

Thank you.

> However, every few months
> or years hobbyists' projects for volunteers to develop an operating
> system in Ada not aimed at embedded targets have been proposed on this
> newsgroup without ever amounting to anything.
>
> Regards,
> Colin Paul Gloster

I sort of figured that was the case; they probably get intimidated by
the sheer amount of work needing to be done for an OS. I'm not saying
I won't, but I do kind of expect it considering that I've been
inactively designing an OS in my head for years.

Re: Writing an Operating System in Ada

[Colin Paul Gloster]

On Tue, 12 Jan 2010, Shark8 wrote:

|-----------------------------------------------------------|
|"[..]                                                      |
|                                                           |
|[..] they probably get intimidated by                      |
|the sheer amount of work needing to be done for an OS. [..]|
|[..]"                                                      |
|-----------------------------------------------------------|

In at least one case something worse and not specific to developing an
operating system terminated or indefinitely paused one of these
projects, but I leave it to the man involved to decide whether or not
to post about it to the newsgroup.

Re: Writing an Operating System in Ada

[Shark8]

On Jan 12, 2:41 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Mon, 11 Jan 2010 17:13:55 -0800 (PST), Shark8 wrote:
> > Anyway, I was wondering if anybody here would be interested in such a
> > project.
>
> If that will be a really new OS (not a UNIX clone), OO, portable,
> distributed etc, for interesting platforms like this:
>
> http://blog.makezine.com/archive/2009/08/scalable_open_source_computi...
>
> why not?
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

You know that was a frustrating / discouraging thing to hear almost
everybody I talked to about wanting to write an OS say something along
the lines of "Why don't you just download the sourcecode for
Linux?"... I'm sorry folks, but I don't want to be the OS equivalent
of a 'script-kiddie'.

One thing I find very annoying about the Unix/Linux mentality is the
"everything is a file" philosophy... coupled with the C/C++-ism of
simply assuming that a file read/write went well and you're asking for
trouble. {Yes, I know that you CAN check to see if writing is
successful or not in C/C++, but it goes against most C/C++
programmer's sense of terseness/'beauty'... the same one that makes no
check on array-bounds.} </Rant>

Now the idea that everything [system-wise] is an object is much more
appealing to me. Objects are a very natural way to [generically] model
hardware: a display has a running-resolution, available resolutions,
OpenGL/DirectX compatibility, etc. It could even be engineered in such
a way that every device-object 'knows' how to write code for its
device and that code is JIT-compiled for the specific system.
(Example: A PCI-card can be inserted unto a system-board with a SPARC
processor, or one with an AMD processor, the two different endian-ness
but the card is the same for both, so it stands to reason that a
device-object [device-driver] could be written in a high-level manner
abstracting out the low-level... probably by having the aforementioned
JIT which is linked to the CPU's device-object tell that object to
output the codes for the PCI-card-object.)

Having such a system means that we could support disparate
architectures by having base-CPU objects & the high-level driver-
objects on a bootable CD with a VM such as DOTNET or JVM and
'installing the OS' would be compiling it for that HW-setup. The
downside to how I'm describing it is that it sounds a little too Unix-
y.

Using the Java-style interfaces we could have a file-system interface
which would allow the OS to use any FS which was implemented in an
object using said interface.

Re: Writing an Operating System in Ada

[Tero Koskinen]

On Tue, 12 Jan 2010 16:21:23 +0000 Colin Paul Gloster wrote:
> On Mon, 11 Jan 2010, Leslie wrote:
> 
> |-----------------------------------------------------------------------|
> |"Shark8 wrote:                                                         |
> |                                                                       |
> |> I was wondering if there would be any interest in coding up an       |
> |> OS in Ada.
...
> |language to user for writing an OS.  I'm not yet proficient in         |
> |Ada, but would be interested in contributing what I can.               |
> |                                                                       |
> |Leslie"                                                                |
> |-----------------------------------------------------------------------|
> 
> If the two of you are willing to implement an operating system in Ada
> then proceed and succeed! I wish you well. However, every few months
> or years hobbyists' projects for volunteers to develop an operating
> system in Ada not aimed at embedded targets have been proposed on this
> newsgroup without ever amounting to anything.

If creating i386/amd64 OS is too hard or big task, another alternative
is to target some embedded board. The easiest option is probably
AVR-Ada[1] and Arduino[2] or some other AVR board.

AVR-Ada works (almost) out of the box on many platforms and
Arduino board costs around 20 euros.

> Regards,
> Colin Paul Gloster

-- 
Tero Koskinen - http://iki.fi/tero.koskinen/

[1] http://sf.net/projects/avr-ada
[2] http://www.arduino.cc/

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Tue, 12 Jan 2010 09:37:11 -0800 (PST), Shark8 wrote:

> On Jan 12, 2:41�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Mon, 11 Jan 2010 17:13:55 -0800 (PST), Shark8 wrote:
>>> Anyway, I was wondering if anybody here would be interested in such a
>>> project.
>>
>> If that will be a really new OS (not a UNIX clone), OO, portable,
>> distributed etc, for interesting platforms like this:
>>
>> http://blog.makezine.com/archive/2009/08/scalable_open_source_computi...
>>
>> why not?
>>
> You know that was a frustrating / discouraging thing to hear almost
> everybody I talked to about wanting to write an OS say something along
> the lines of "Why don't you just download the sourcecode for
> Linux?"... I'm sorry folks, but I don't want to be the OS equivalent
> of a 'script-kiddie'.
> 
> One thing I find very annoying about the Unix/Linux mentality is the
> "everything is a file" philosophy... coupled with the C/C++-ism of
> simply assuming that a file read/write went well and you're asking for
> trouble. {Yes, I know that you CAN check to see if writing is
> successful or not in C/C++, but it goes against most C/C++
> programmer's sense of terseness/'beauty'... the same one that makes no
> check on array-bounds.} </Rant>

Wow, can you read minds? (:-)) I wrote about something like that many many
years ago. Yes, "everything is a file", "fore every possible job is a
utility", "every action is a process" is a pest of UNIX.

> Now the idea that everything [system-wise] is an object is much more
> appealing to me.

World-wise (a modern OS must be distributed)

> Objects are a very natural way to [generically] model
> hardware: a display has a running-resolution, available resolutions,
> OpenGL/DirectX compatibility, etc. It could even be engineered in such
> a way that every device-object 'knows' how to write code for its
> device and that code is JIT-compiled for the specific system.
> (Example: A PCI-card can be inserted unto a system-board with a SPARC
> processor, or one with an AMD processor, the two different endian-ness
> but the card is the same for both, so it stands to reason that a
> device-object [device-driver] could be written in a high-level manner
> abstracting out the low-level... probably by having the aforementioned
> JIT which is linked to the CPU's device-object tell that object to
> output the codes for the PCI-card-object.)
> 
> Having such a system means that we could support disparate
> architectures by having base-CPU objects & the high-level driver-
> objects on a bootable CD with a VM such as DOTNET or JVM and
> 'installing the OS' would be compiling it for that HW-setup. The
> downside to how I'm describing it is that it sounds a little too Unix-
> y.
> 
> Using the Java-style interfaces we could have a file-system interface
> which would allow the OS to use any FS which was implemented in an
> object using said interface.

There should be no file system at all. If you have objects, I mean if you
do have them consistently all the way, then you do not need files. Make
objects persistent in the corresponding device, that gives you all
functionality of any file. No I/O is ever needed. Map the object into the
memory, call its operations, what else any program would have to do?

The problem is that we followed the wrong path for too long. All these
standards (XML to name one) are based on these flawed untyped file - "don't
care about the contents" model. There could be no return, maybe.

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

Re: Writing an Operating System in Ada

[Shark8]

> Wow, can you read minds? (:-))

I've been accused of it... but those are merely accusations. ;)

> > Now the idea that everything [system-wise] is an object is much more
> > appealing to me.
>
> World-wise (a modern OS must be distributed)

I'm not overly-sure about that. It still makes sense, especially from
a security-standpoint, to have systems which are isolated. But on the
whole, yes it needs to have that sort of extensibility. I think the
best idea would be to metaphorically "borrow recursion" for the
distribution-design such that a single computer is the 'base case'.

> > Having such a system means that we could support disparate
> > architectures by having base-CPU objects & the high-level driver-
> > objects on a bootable CD with a VM such as DOTNET or JVM and
> > 'installing the OS' would be compiling it for that HW-setup. The
> > downside to how I'm describing it is that it sounds a little too Unix-
> > y.
>
> > Using the Java-style interfaces we could have a file-system interface
> > which would allow the OS to use any FS which was implemented in an
> > object using said interface.
>
> There should be no file system at all. If you have objects, I mean if you
> do have them consistently all the way, then you do not need files. Make
> objects persistent in the corresponding device, that gives you all
> functionality of any file. No I/O is ever needed. Map the object into the
> memory, call its operations, what else any program would have to do?

I agree for the most part and would want Files to be full objects
themselves... and since objects 'know' their own type so would these
files. Perhaps having files be their own objects with a mix-in of a
stream would be a wiser choice... or they could all be descended from
an abstract-stream-object. {Files SHOULD be typed, absolutely.}

The problem about having no I/O is that there are some file-formats
which ARE sequential-in-nature as opposed to Random-access/Record-in-
nature: Midi and Huffman encoding (actually MOST compression would
fall here) are to examples off the top of my head. Or am I
misunderstanding what you mean?

> The problem is that we followed the wrong path for too long. All these
> standards (XML to name one) are based on these flawed untyped file - "don't
> care about the contents" model. There could be no return, maybe.

XML is ugly. Really ugly. EA's IFF was/is more interesting. And with
Ada'a inherent ability to read/write most types directly to/from a
stream it XML would be fairly unnecessary. The original purpose for
XML being: "describe a type-layout" (the DTD) now everything can use
that layout (basically an instance of that record)!

Re: Writing an Operating System in Ada

[Maciej Sobczak]

On 12 Sty, 20:56, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> There should be no file system at all. If you have objects, I mean if you
> do have them consistently all the way, then you do not need files. Make
> objects persistent in the corresponding device, that gives you all
> functionality of any file. No I/O is ever needed. Map the object into the
> memory, call its operations, what else any program would have to do?

Interact with other systems? You know, you might want to sometimes
move your "persistent objects" to another machine.

Did I mention that you might want to move you whole hard drive to
another machine as well? :-)

There is a reason why none of the pure-OO-OS-let's-do-it-correctly
ever really took off.

> The problem is that we followed the wrong path for too long.

There is nothing wrong with that path, as it happens to be very
pragmatic.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Writing an Operating System in Ada

[nobody]

Shark8 wrote:
> The problem about having no I/O is that there are some file-formats
> which ARE sequential-in-nature as opposed to Random-access/Record-in-
> nature: Midi and Huffman encoding (actually MOST compression would
> fall here) are to examples off the top of my head. Or am I
> misunderstanding what you mean?

That is just implementation details that should(can) be hidden from the 
application code. Stick to the objects. Don't forget associations.

Re: Writing an Operating System in Ada

[Shark8]

On Jan 12, 3:39 pm, nobody <nob...@nowhere.com> wrote:
> Shark8 wrote:
> > The problem about having no I/O is that there are some file-formats
> > which ARE sequential-in-nature as opposed to Random-access/Record-in-
> > nature: Midi and Huffman encoding (actually MOST compression would
> > fall here) are to examples off the top of my head. Or am I
> > misunderstanding what you mean?
>
> That is just implementation details that should(can) be hidden from the
> application code. Stick to the objects. Don't forget associations.

Aren't associations rather trivial if we derive all files from some
base tagged-type and use the tag as the type-identifier?

Re: Writing an Operating System in Ada

[Shark8]

On Jan 12, 2:52 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 12 Sty, 20:56, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>
> > There should be no file system at all. If you have objects, I mean if you
> > do have them consistently all the way, then you do not need files. Make
> > objects persistent in the corresponding device, that gives you all
> > functionality of any file. No I/O is ever needed. Map the object into the
> > memory, call its operations, what else any program would have to do?
>
> Interact with other systems? You know, you might want to sometimes
> move your "persistent objects" to another machine.
>
> Did I mention that you might want to move you whole hard drive to
> another machine as well? :-)

True, systems may be fairly static: like my old desktop. Or they may
be fairly dynamic, being updated/improved regularly. It would be
pretty dumb to force someone's data to be bound to a certain system,
like certain DRM-pilious companies. While we can be fairly certain
that many things will be the same, such as the CPU's family, to
completely disregard such exceptional (or regular in the case of some
distributed systems) circumstances is valid only in academia or some
project where you are GUARANTEED to have only a single configuration [-
set] to deal with.

Gaming platforms come to mind there, as well as Macs where the company
controls hardware.

> There is a reason why none of the pure-OO-OS-let's-do-it-correctly
> ever really took off.

I think you're getting a valid point there. It makes more sense to me
to have file-objects derived from some stream-type and then having
that stream directed [and possibly transformed, as need be] by the
filesystem-object to the drive. {A FS may be of the opposite endianess
than the system which is accessing the data, this is a non-issue if it
is ALWAYS read & written the same way BUT if you were to port the
drive to a system with the same endianness the reading and writing
would be mixed-up.}

IE - in the high-level world Write(Integer) and Read(Integer) are
completely safe... but if another system were to read/write the data
in the opposite endianess bad things happen.

> > The problem is that we followed the wrong path for too long.
>
> There is nothing wrong with that path, as it happens to be very
> pragmatic.

The main problem is, I think, the API-standard of keying, to borrow
from databases, on the (Location, Name) Tuple. If we consider the name
of a file as a mutable attribute then we must use some other criteria
for identifying files. (ie it makes little sense to have a file become
invalid because you used the standard 'rename' command.) For a local
system we could use the GUID of a 64-bit word, however this system
would not work well for distributed/remote/networked systems because,
in the absence of proper communication some other Index may be added
by two different systems trying to ID a certain file. I would suggest
using a vector of hashes to key [UUID] File-ID across a network, say:
(MD5, SHA1, XOR-32). This would have the drawback of generating a new
ID every time the file is updated... though that could be overcome by
allowing the OS to track such changes with versioning or redirects or
somesuch.

GUID : Globally Unique IDentifier. (Longitude, Latitude) is a GUID.
UUID : Universally Unique IDentifier. (Longitude, Latitude) is NOT a
UUID because different planets have the same (Long., Lat.) tuple, in
order to be a UUID we would have to indicate which planet we are
talking about, like this: (Name, Long., Lat.).

Re: Writing an Operating System in Ada

[Leslie]

Shark8 wrote:

> On Jan 12, 2:41 am, "Dmitry A. Kazakov"
> <mail...@dmitry-kazakov.de> wrote:
>> On Mon, 11 Jan 2010 17:13:55 -0800 (PST), Shark8 wrote:
>> > Anyway, I was wondering if anybody here would be interested
>> > in such a project.
>>
>> If that will be a really new OS (not a UNIX clone), OO,
>> portable, distributed etc, for interesting platforms like
>> this:
>>
>>
http://blog.makezine.com/archive/2009/08/scalable_open_source_computi...
>>
>> why not?
>>
>> --
>> Regards,
>> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de
> 
> You know that was a frustrating / discouraging thing to hear
> almost everybody I talked to about wanting to write an OS say
> something along the lines of "Why don't you just download the
> sourcecode for Linux?"... I'm sorry folks, but I don't want to
> be the OS equivalent of a 'script-kiddie'.
> 
> One thing I find very annoying about the Unix/Linux mentality
> is the "everything is a file" philosophy... coupled with the
> C/C++-ism of simply assuming that a file read/write went well
> and you're asking for trouble. {Yes, I know that you CAN check
> to see if writing is successful or not in C/C++, but it goes
> against most C/C++ programmer's sense of terseness/'beauty'...
> the same one that makes no check on array-bounds.} </Rant>

        If possible, also, it would be nice to get away from the "root
can do anything" paradigm, and its associated inherited
privileges (crash a root-capable process and steal its
privileges).  It would be nice to see something more like the
explicit privilege design used by CP in IBM's VM operating
systems.
        As a side note, does anyone here remember the Intel iAPX432
processor, designed to execute Ada programs (almost) directly?

Leslie

Re: Writing an Operating System in Ada

[Hibou57 (Yannick Duchêne)]

On 12 jan, 10:41, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
>
> If that will be a really new OS (not a UNIX clone), OO, portable,
> distributed etc, for interesting platforms like this:
>
> http://blog.makezine.com/archive/2009/08/scalable_open_source_computi...
>
> why not?
Exactly the kind of things I'm dreaming about since about 12 years.
Thanks for the link.

The computer industry should have choose this way instead of the one
of big CPUs and big monolithic motherboards. At the time of the i486,
before the Pentium was released, I though there may be a break in the
architecture and the i486 was the last of its kind, and that something
new gonna came up. I was disappointed when I heard about the Pentium
and though inside of me "Oh shit, they persist and still go-on in this
way"

Re: Writing an Operating System in Ada

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:

> The problem is that we followed the wrong path for too long. All these
> standards (XML to name one) are based on these flawed untyped file - "don't
> care about the contents" model. There could be no return, maybe.

The name "Don't care about the operations" model of file systems seems
adequate because virtually all contemporary file systems and
archive formats offer file type indication (via extended
attributes). Only the C and Ada libraries typically do not make
programmers aware of this fact.

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Tue, 12 Jan 2010 13:52:40 -0800 (PST), Maciej Sobczak wrote:

> On 12 Sty, 20:56, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> There should be no file system at all. If you have objects, I mean if you
>> do have them consistently all the way, then you do not need files. Make
>> objects persistent in the corresponding device, that gives you all
>> functionality of any file. No I/O is ever needed. Map the object into the
>> memory, call its operations, what else any program would have to do?
> 
> 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.

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

This is not a question of objects or raw blocks. If the OS recognizes the
pluggable component, there is no problem, if it does not there is a
problem. Nothing prevents a portable design of persistent storage.

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

> 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. Without MI, MD, tagged tasks, there is no chance to get
it right. But the major problem is lack of any interest, since the market
of operating system was burnt down to the ground.

>> The problem is that we followed the wrong path for too long.
> 
> There is nothing wrong with that path, as it happens to be very
> pragmatic.

Maybe. If we compared the computing power we had in i386 days with the
power of a modern machine (that includes not only the CPUs but also all
processors and micro controllers on board). Is this increase of power
matched by what the software provides? I don't think it is. The
"pragmatism" was, if you have a software problem, buy a new computer. That
might be economically OK, but it still is bad for the software. In long
term perspective we sooner or later will be forced to use computing
resources more efficiently.

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

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Wed, 13 Jan 2010 10:09:58 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
> 
>> The problem is that we followed the wrong path for too long. All these
>> standards (XML to name one) are based on these flawed untyped file - "don't
>> care about the contents" model. There could be no return, maybe.
> 
> The name "Don't care about the operations" model of file systems seems
> adequate because virtually all contemporary file systems and
> archive formats offer file type indication (via extended
> attributes).

Oh yes, it is a shoe carton with a big fat label on it: "Mercedes". Look,
it is not the label, but the operations, which make the thing what it is. A
shoe carton is a carton no matter how you name it. A file is an object with
the operations getc, putc, period. Mercedes is an object with the
operations drive etc.

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

Re: Writing an Operating System in Ada

[Martin]

On Jan 13, 3:38 am, Leslie <jlturr...@centurytel.net> wrote:
> Shark8 wrote:
> > On Jan 12, 2:41 am, "Dmitry A. Kazakov"
> > <mail...@dmitry-kazakov.de> wrote:
> >> On Mon, 11 Jan 2010 17:13:55 -0800 (PST), Shark8 wrote:
> >> > Anyway, I was wondering if anybody here would be interested
> >> > in such a project.
>
> >> If that will be a really new OS (not a UNIX clone), OO,
> >> portable, distributed etc, for interesting platforms like
> >> this:
>
> http://blog.makezine.com/archive/2009/08/scalable_open_source_computi...
>
>
>
>
>
> >> why not?
>
> >> --
> >> Regards,
> >> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de
>
> > You know that was a frustrating / discouraging thing to hear
> > almost everybody I talked to about wanting to write an OS say
> > something along the lines of "Why don't you just download the
> > sourcecode for Linux?"... I'm sorry folks, but I don't want to
> > be the OS equivalent of a 'script-kiddie'.
>
> > One thing I find very annoying about the Unix/Linux mentality
> > is the "everything is a file" philosophy... coupled with the
> > C/C++-ism of simply assuming that a file read/write went well
> > and you're asking for trouble. {Yes, I know that you CAN check
> > to see if writing is successful or not in C/C++, but it goes
> > against most C/C++ programmer's sense of terseness/'beauty'...
> > the same one that makes no check on array-bounds.} </Rant>
>
>         If possible, also, it would be nice to get away from the "root
> can do anything" paradigm, and its associated inherited
> privileges (crash a root-capable process and steal its
> privileges).  It would be nice to see something more like the
> explicit privilege design used by CP in IBM's VM operating
> systems.
>         As a side note, does anyone here remember the Intel iAPX432
> processor, designed to execute Ada programs (almost) directly?
>
> Leslie

Nope...but I wish we'd gone for the Ericsson D80A processor (with Ada
(83) runtime in firmware) and not the Motorola 68040! We'd used the
D80 and the D80E which were fantastic processors, not sure why the
decision went the way it did...great support from Ericsson back then
too...

Cheers
-- Martin

Re: Writing an Operating System in Ada

[Lucretia]

On Jan 12, 1:13 am, Shark8 <onewingedsh...@gmail.com> wrote:
> I was wondering if there would be any interest in coding up an OS in
> Ada. I don't mean taking an existing codebase and rewriting/converting
> it to Ada, but implementing it from the ground up. It's been a bit of
> a "for later" project for me to write an OS, although I did begin to
> write one in Turbo Pascal which got to the point of being able to
> recognize user-commands & (based on those commands) change the screen
> resolution. {And all using less than ten lines of inline assembly!}
>
> As time went on the project went on the back-burner and "later" never
> really came around, but in that meantime I was finishing up my degree
> in CS and came across Ada in my senior-level programming languages
> class. The design of Ada impressed me a lot and so I got myself
> Barnes's Ada 2005 book and started teaching myself. (So, in reality
> I'm pretty new to Ada, but I do come from a Pascal background and like
> the idea of having my compiler check things for correctness.)
>
> Anyway, I was wondering if anybody here would be interested in such a
> project.

Me too, I wrote a "hello world" kernel in Ada ages ago and posted it
up onto my blog site: http://www.archeia.com - it's a tad slow though
so will be moving my site over to a new one when I get around to it :D

I'll also be getting back to the OS (when I get around to it :D).

Luke.

Re: Writing an Operating System in Ada

[Ad Buijsen]

Leslie wrote:

> 
>         If possible, also, it would be nice to get away from the "root
> can do anything" paradigm, and its associated inherited
> privileges (crash a root-capable process and steal its
> privileges).  It would be nice to see something more like the
> explicit privilege design used by CP in IBM's VM operating
> systems.

A capability-based OS, like Coyotos, perhaps?

The latest version of Genode (announced in this group) supports 
components programmed in SPARK; this allows a gentle entry to building 
an OS by piecemeal replacement of servers, and possibly even the 
microkernel.

Ad Buijsen

Re: Writing an Operating System in Ada

[Shark8]

> > 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? Is the assignment atomic? 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?

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

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

> if it does not there is a
> problem. Nothing prevents a portable design of persistent storage.

You are correct. And that is what a file-system IS. The design of [a
method] for persistent storage.

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

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

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

Now let's say we extend our families of letters and numbers by a
single item we get the following:

(A,1)
(A,2)
(A,3)
(B,1)
(B,2)
(B,3)
(C,1)
(C,2)
(C,3)

And each of these instances must be defined because we have no way to
restrict invalid combinations, and if we don't restrict invalid
combinations we quickly run into huge data-sets that are [mostly]
worthless. If multi-dispatch were sorting it's somewhat akin to having
bubble-sort be your only method of sorting. We don't have efficient/
proper techniques for dealing with it.

> In long
> term perspective we sooner or later will be forced to use computing
> resources more efficiently.

Indeed, I completely agree. Which is actually the reason I named my OS
after the Commodore; if we could have the same 'wow' level of
effectiveness & efficiency given current hardware as they did then, I
believe that we would have normal-people absolutely astounded at what
their computer could do.

Re: Writing an Operating System in Ada

[Shark8]

> > I was wondering if there would be any interest in coding up an OS in
> > Ada. I don't mean taking an existing codebase and rewriting/converting
> > it to Ada, but implementing it from the ground up. [SNIP!]
> >
> > Anyway, I was wondering if anybody here would be interested in such a
> > project.
>
> Me too, I wrote a "hello world" kernel in Ada ages ago and posted it
> up onto my blog site:http://www.archeia.com- it's a tad slow though
> so will be moving my site over to a new one when I get around to it :D
>
> I'll also be getting back to the OS (when I get around to it :D).
>
> Luke.

Nifty. I came across your blog a while back as I was looking up some
Ada 2005 features (thank you for your explanation, in particular);
it's pretty good, IMO. If you'd like to pop me an e-mail or IM and
talk-shop about OS/OS-design I'd be more than happy to do so. {The
same goes for everyone else who's interested.}

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

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

Re: Writing an Operating System in Ada

[Shark8]

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

Why do you say that? I see them as just being a contract for functions/
procedures that some object must provide, and in that sense there is
no reason why an actual object-class cannot agree to one or more of
these 'contracts'. One nice thing Delphi did was to allow an interface
to be implemented by a field of the class, they called this "interface
delegation" and looked something like this:
Type TExample = Class(TObject, IDelegated)
  private
   DelegationField : TSomeDelegatedObject;
  public
   property Delagator : TSomeDelegatedObject read DelegationField
write DelegationField implements IDelegated;
end; //Example

I suppose you could call it 'subcontracting'.

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

Good point.

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

That depends if the hardware requires it, older system boards didn't
have the power-supply coupled to the fan. And there are plenty of
[small] system-boards that don't have fans, like the HC11 I played
with. So, I suppose the best answer would be: "It's a matter of
design."

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

The physical drive itself.... it has to be recognized in order to get
the "do you want to format?"-style message in the first place.

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

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?

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

I think I see what you're saying here, but abstraction _is_ one of the
"big ideas" in computer science. If we're speaking of the hardware-
interfaces we can see that there are some decided advantages to
abstraction, take SCSI for example: SCSI devices transfer data on a
higher-level than IDE by way of the SCSI-commands & the SCSI-protocol
(which allows the host to reorder requests for optimal service).

The only reason you need drivers for a SCSI card is so that SCSI-host
and the OS can communicate. This is done in a manner very similar to
Ada's spec/implementation divide. In our data-system/library example
this would be like a professor telling TA "go get me such-and-such
book". (The CPU playing the role of the professor & the SCSI-hose as
the TA.)

Perhaps the problem of miscommunication from earlier was due to
misconstruing what I was trying to say regarding a "file-system-
object"  and its role; the role I'm thinking of is that of, in the
aforementioned metaphor, would be the librarian... that is someone who
knows how to read index-by-title/author/decimal (FAT32/ext4/Reiser/
etc) AND knows how to map that index into actual location (shelf/box/
etc).

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

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Wed, 13 Jan 2010 14:50:50 -0800 (PST), Shark8 wrote:

>>> 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.
> 
> Why do you say that?

Because there should be a honest MI and no interfaces. 

> I see them as just being a contract for functions/
> procedures that some object must provide, and in that sense there is
> no reason why an actual object-class cannot agree to one or more of
> these 'contracts'. One nice thing Delphi did was to allow an interface
> to be implemented by a field of the class, they called this "interface
> delegation" and looked something like this:
> Type TExample = Class(TObject, IDelegated)
>   private
>    DelegationField : TSomeDelegatedObject;
>   public
>    property Delagator : TSomeDelegatedObject read DelegationField
> write DelegationField implements IDelegated;
> end; //Example

You do not need explicitly named contracts in a language like Ada. The
contract of a type is the type itself. Ada has type declarations, public
and private. Everything visible related to the type is the contract of.
Period.

> I suppose you could call it 'subcontracting'.

There should be plain interface inheritance instead.

If you wanted the type S to implement the interface of the type T *without*
inheriting the implementation of T, you should be able to tell just so. 

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.

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

>>>> Without MI, MD, tagged tasks, there is no chance to get
>>>> it right.
>>
>>
>>> 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? (:-))

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

Re: Writing an Operating System in Ada

[Jean-Pierre Rosen]

Leslie a écrit :
>         As a side note, does anyone here remember the Intel iAPX432
> processor, designed to execute Ada programs (almost) directly?
> 
Yes I do. IIRC, the project failed because they completely missed the
point. The processor was intended to be able to check the types of data
at run-time, something that the compiler had already done. In a sense,
it would have been a marvelous processor for any language but Ada -
bringing Ada's type safety to other languages.

There was a team who developped an Ada compiler for the iAPX432. When
the project was disbanded, they were so frustrated that they decided to
move their compiler to other targets and market it. The company was
called Verdix...

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Writing an Operating System in Ada

[Maciej Sobczak]

On 13 Sty, 10:17, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
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.

What remote object? I just plugged in my USB stick or spun the DVD in
the drive.

If you want to see a "remote object" in this operation, you will have
to somehow instruct the system that the "remote object" is the one
which is on USB. In which case there is no point in having it
(unnecessary step) as you might just as well instruct the system that
your *local* object should be constructed from what is on the drive,
by perhaps providing the file name.

Which is exactly what we have today.

The high-level OO abstraction still has to hit the bare metal at some
point, which only shows that it does not solve any problem, only moves
it elsewhere.

> > Did I mention that you might want to move you whole hard drive to
> > another machine as well? :-)
>
> Did you try?

Sure, my USB stick works fine.

> What happens with a NTFS drive in a Linux system?

I have no idea since I do not have any NTFS drives around. :-)

But I do not see how the OO approach would solve that problem. Plug
the OO-aware drive from the OO-aware system from Microsoft into your
OO-aware system of choice and you will be in the same mess.

Again, no problem solved.

(because the problem of compatibility is in standardization, not in
paradigm)

> > 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. Without MI, MD, tagged tasks, there is no chance to get
> it right.

Agreed. OO cannot be done right without these sorted out first.

> But the major problem is lack of any interest, since the market
> of operating system was burnt down to the ground.

Or maybe the problem is that people try to perceive any given paradigm
as a silver bullet for solving all problems. I do not think that OO is
one (and I though the industry came to this conclusion some 15 years
ago already).
Personally, I'm not even sure if I would like to use the OS that was
made pure-OO from the ground up in all possible aspects. Some paradigm
flexibility is needed to find optimal solutions in different
situations and that cannot be achieved if a single idea is driving
everything.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Thu, 14 Jan 2010 01:40:57 -0800 (PST), Maciej Sobczak wrote:

> On 13 Sty, 10:17, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> 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.
> 
> What remote object? I just plugged in my USB stick or spun the DVD in
> the drive.

You said you wanted to move an object.

> If you want to see a "remote object" in this operation, you will have
> to somehow instruct the system that the "remote object" is the one
> which is on USB. In which case there is no point in having it
> (unnecessary step) as you might just as well instruct the system that
> your *local* object should be constructed from what is on the drive,
> by perhaps providing the file name.

I.e. you don't want to move it... (:-))

> Which is exactly what we have today.
> 
> The high-level OO abstraction still has to hit the bare metal at some
> point, which only shows that it does not solve any problem, only moves
> it elsewhere.

Absolutely. Also no programming language solves anything about that. In the
end it is the p-n-p transistors which do the job. What is the point?

>>> Did I mention that you might want to move you whole hard drive to
>>> another machine as well? :-)
>>
>> Did you try?
> 
> Sure, my USB stick works fine.

Because it has FAT, which is supported.

>> What happens with a NTFS drive in a Linux system?
> 
> I have no idea since I do not have any NTFS drives around. :-)
> 
> But I do not see how the OO approach would solve that problem. Plug
> the OO-aware drive from the OO-aware system from Microsoft into your
> OO-aware system of choice and you will be in the same mess.

Sure. But your argument was that a file system would handle it better. It
does not.

> Again, no problem solved.

Yes, the only solution of the problem is to write some code. You can write
it in assembler, C, Ada etc. But the code must be written. So the problem
is how do we write the code, and not whether there should be some.

> (because the problem of compatibility is in standardization, not in
> paradigm)

Standards reduce the number of variants to support. But note that the
standards themselves are influenced by the state of the art. Consider POSIX
as an example. If there were no UNIX, the standard would be very different.

>> But the major problem is lack of any interest, since the market
>> of operating system was burnt down to the ground.
> 
> Or maybe the problem is that people try to perceive any given paradigm
> as a silver bullet for solving all problems.

No. It is because people tend to buy only silver bullets. So whatever you
sell, you better do it as such.

> I do not think that OO is
> one (and I though the industry came to this conclusion some 15 years
> ago already).

Yep.

> Personally, I'm not even sure if I would like to use the OS that was
> made pure-OO from the ground up in all possible aspects. Some paradigm
> flexibility is needed to find optimal solutions in different
> situations and that cannot be achieved if a single idea is driving
> everything.

What is the opposite paradigm? I don't care much about OO, I do about ADT.
The real alternatives are typed vs untyped. I think we have been using the
latter for too long and it won't stand up safety and quality requirements
of future omnipresent computing.

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

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Thu, 14 Jan 2010 10:12:25 +0100, Jean-Pierre Rosen wrote:

> Yes I do. IIRC, the project failed because they completely missed the
> point. The processor was intended to be able to check the types of data
> at run-time, something that the compiler had already done. In a sense,
> it would have been a marvelous processor for any language but Ada -
> bringing Ada's type safety to other languages.

I disagree. One could perfectly complement another. If you wanted to create
a safe OS you would like to protect system objects at the hardware level
independently on whether the language does any checks or not.

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

Re: Writing an Operating System in Ada

[Jean-Pierre Rosen]

Dmitry A. Kazakov a �crit :
> I disagree. One could perfectly complement another. If you wanted to create
> a safe OS you would like to protect system objects at the hardware level
> independently on whether the language does any checks or not.
> 
They claimed that the CPU was "putting Ada on silicon". What I mean is
that the value of Ada is to check many things at compile time; anything
that's on silicon will have to wait until execution time.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Thu, 14 Jan 2010 12:31:01 +0100, Jean-Pierre Rosen wrote:

> Dmitry A. Kazakov a �crit :
>> I disagree. One could perfectly complement another. If you wanted to create
>> a safe OS you would like to protect system objects at the hardware level
>> independently on whether the language does any checks or not.
>> 
> They claimed that the CPU was "putting Ada on silicon". What I mean is
> that the value of Ada is to check many things at compile time; anything
> that's on silicon will have to wait until execution time.

Well, Ada has a cooperative model of accessing things, i.e. whatever the
compiler has checked, that gives no any guaranty at run time. We could also
imagine a variant of the language that would give such guaranties if
demanded. For example a protected object could be mapped outside the
process's space. When calling an operation on it, the OS would check the
provided object address and execute the protected operation in the kernel
mode. This is how many OSes handle I/O requests. They check the request
parameters for being valid addresses in the process space. They also check
certain types. When you pass a handle to some system object, it is checked
if that is a brush, when used in Paint. That sort of things could be
supported by the hardware reducing the overhead of system calls. Shared
libraries would certainly win from such design too. So there is nothing
wrong in this idea, and it is in no contradiction with static checks.

(What iAPX432 was actually designed for is another story)

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

Re: Writing an Operating System in Ada

[Shark8]

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

Re: Writing an Operating System in Ada

[tmoran]

> > What remote object? I just plugged in my USB stick or spun the DVD in
> > the drive.
>
> You said you wanted to move an object.
  Files are rather special objects in that one often drastically changes
the abstraction level at which they are viewed.  Is a movie on a DVD an
object?  How about the .vob files that contain the actual video?  If you
want to do a virus scan on a .vob file, it's not a video file - it's
a series of bytes.

Re: Writing an Operating System in Ada

[tmoran]

> Yes I do. IIRC, the project failed because they completely missed the
> point. The processor was intended to be able to check the types of data
> at run-time, something that the compiler had already done.
  Not all code is generated by Ada compilers.  A secure processor
could help defend against virus infections.

Re: Writing an Operating System in Ada

[tmoran]

> > 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.
  The desktop on my computer rarely looks similar to a piece of paper on
my real desk.  I doubt Postscript is an equally good description language
for both.  Didn't the Next computer use Postscript?  And do current Macs?

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Thu, 14 Jan 2010 18:57:24 +0000 (UTC), tmoran@acm.org wrote:

>>> What remote object? I just plugged in my USB stick or spun the DVD in
>>> the drive.
>>
>> You said you wanted to move an object.
>   Files are rather special objects in that one often drastically changes
> the abstraction level at which they are viewed.  Is a movie on a DVD an
> object?

Yes

> How about the .vob files that contain the actual video?

No files

> If you
> want to do a virus scan on a .vob file, it's not a video file - it's
> a series of bytes.

I don't need to scan for viruses an object which single operation is play
(takes the device context as the second parameter).

Virus is a problem caused by lack of typing.

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

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

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

Re: Writing an Operating System in Ada

[Georg Bauhaus]

On 1/14/10 8:19 PM, Dmitry A. Kazakov wrote:
> On Thu, 14 Jan 2010 18:57:24 +0000 (UTC), tmoran@acm.org wrote:

>> If you
>> want to do a virus scan on a .vob file, it's not a video file - it's
>> a series of bytes.
>
> I don't need to scan for viruses an object which single operation is play
> (takes the device context as the second parameter).

You'd need to scan the video for hidden espionage data,
or for a hidden message that if delivered will save a life.

You'd need to scan the video for information related to color,
brightness, etc. when adjusting cinema equipment to
current weather conditions.

Do all these operations need to override "play" accordingly,
or are you thinking of using Cartesian product types created
as needed, maybe?
Will all persistent video objects be extensible so that they can
provide the necessary subprograms that some use case needs?

Re: Writing an Operating System in Ada

[Shark8]

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

Ah, but this brings up a question: HOW do we change it?

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

But isn't B.F exactly equal to C.F in that we're using an inherited
procedure/function? The diamond problem is about components named the
same that have different types... because interfaces ARE abstract
objects (with the further restriction that they are denied fields)
they don't suffer from the diamond problem. {That is the footprint of
Procedure Foo is EXACTLY the same in all three, they are all the
same.}

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

You're right I forgot the 'Class. But the problem still stands with it
rewritten as such.

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

True. But if we're talking about an OO hierarchy then a derived-member
of some class IS a superset of that class; and also as things fall
into a nice hiearchy, we see that these classes themselves are sets.

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

LOL

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

I think it points to a bad design. IMO, I think something like this
would be in order:

Type Abstract_File is limited interface;
-- All abstractable file operations go here.
Function Readable( File : in Abstract_File ) return Boolean is
Abstract;
Function Writable( File : in Abstract_File ) return Boolean is
Abstract;
Procedure Read ( File : in Abstract_File; Stream :
Stream_Class'Class ) is Abstract;
Procedure Write( File : in Abstract_File; Stream :
Stream_Class'Class ) is Abstract;
-- And so forth.

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

That doesn't answer the WHY question.

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

Um, are you forgetting the librarian/library/book metaphor from
earlier? The FILE is like the book, it's type is a property of the
abstract-type "book," the Library is the physical drive where you go
to get said book, the librarian is the one who knows how to traverse
the organization/disorganization within the library is the FS. (Not
all FSes are Hierarchical, think of them as some ADT holding some
File'Class objects.)

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

I remember reading that now... but is an inheritance level of 1 good
enough? Possibly if we were to abstract things in the correct manner.
If the inheritance level is one, is it also legal to have task types
Abstract_Program and Abstract_something which are both implemented in
a single class/case? {It would have the requisite depth of 1...}

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Thu, 14 Jan 2010 21:33:25 +0100, Georg Bauhaus wrote:

> On 1/14/10 8:19 PM, Dmitry A. Kazakov wrote:
>> On Thu, 14 Jan 2010 18:57:24 +0000 (UTC), tmoran@acm.org wrote:
> 
>>> If you
>>> want to do a virus scan on a .vob file, it's not a video file - it's
>>> a series of bytes.
>>
>> I don't need to scan for viruses an object which single operation is play
>> (takes the device context as the second parameter).
> 
> You'd need to scan the video for hidden espionage data,
> or for a hidden message that if delivered will save a life.

If you cannot scan it, how are you going to get the message from? (:-))

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

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Thu, 14 Jan 2010 13:07:08 -0800 (PST), Shark8 wrote:

>>>>> 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. (:-))
> 
> Ah, but this brings up a question: HOW do we change it?

1. AI is sent to ARG. 2. ARG accepts AI. 3. ISO receives an amendment. 4.
Springer Verlag prints the text... Or are you asking me how to implement
MI? (:-))

>>> 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.
> 
> But isn't B.F exactly equal to C.F in that we're using an inherited
> procedure/function?

Nope. A is an abstract list node, F is the operation get next node in the
list. B is the list of devices. C is the list processes. Each note
participates in two lists.

> The diamond problem is about components named the
> same that have different types... because interfaces ARE abstract
> objects (with the further restriction that they are denied fields)
> they don't suffer from the diamond problem. {That is the footprint of
> Procedure Foo is EXACTLY the same in all three, they are all the
> same.}

Wrong:

1. There is no whatsoever difference between operations and fields. Each
field is equivalent to a pair of primitive operations (getter and setter).

2. Whether an inheritance is additive or else idempotent depends on the
problem space. It is not the language designer's choice. It is a common
mistake to think otherwise. All misconceptions about MI stem from there.

>>>> 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.
> 
> You're right I forgot the 'Class. But the problem still stands with it
> rewritten as such.

There is no problem, it is up to the programmer to decide about 2. If he
chooses button interface to be additive, as in your case, the compiler
shall support his choice. This is pretty simple to do because in Ada these
conflicts are statically checkable.

Resolving such conflicts is also no big deal. For example, one can rename
operations upon inheritance hiding the conflicting ones.

>> 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;
> 
> I think it points to a bad design. IMO, I think something like this
> would be in order:
> 
> Type Abstract_File is limited interface;
> -- All abstractable file operations go here.
> Function Readable( File : in Abstract_File ) return Boolean is
> Abstract;
> Function Writable( File : in Abstract_File ) return Boolean is
> Abstract;
> Procedure Read ( File : in Abstract_File; Stream :
> Stream_Class'Class ) is Abstract;
> Procedure Write( File : in Abstract_File; Stream :
> Stream_Class'Class ) is Abstract;
> -- And so forth.

1. Since when God-classes became good design?

2. Your design defeats the very advantages of Ada as a statically typed
language. I want Write to be *statically* checked. Otherwise I would use a
dynamically typed language there are plenty of.

>> 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.
> 
> That doesn't answer the WHY question.

I don't propose to have no containers.

>>> 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.
> 
> Um, are you forgetting the librarian/library/book metaphor from
> earlier? The FILE is like the book, it's type is a property of the
> abstract-type "book," the Library is the physical drive where you go
> to get said book, the librarian is the one who knows how to traverse
> the organization/disorganization within the library is the FS. (Not
> all FSes are Hierarchical, think of them as some ADT holding some
> File'Class objects.)

I don't understand how this is related to the question how to handle books.

>>>>>>>> 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.
> 
> I remember reading that now... but is an inheritance level of 1 good
> enough?

No, it is not. The bottom level is an interface, a quite useless thing
because it does not provide implementation. The next level is a concrete
implementation. The train stops there.

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

Re: Writing an Operating System in Ada

[Maciej Sobczak]

On 14 Sty, 11:28, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > But I do not see how the OO approach would solve that problem. Plug
> > the OO-aware drive from the OO-aware system from Microsoft into your
> > OO-aware system of choice and you will be in the same mess.
>
> Sure. But your argument was that a file system would handle it better. It
> does not.

The file system handles the data exchange between systems that were
written with different paradigms in mind.
Your objects would be transportable only between OO systems. That
would be a huge portability limitation for me.

In this context, the advantage of the file system is that it does not
impose any assumptions about the OS itself. That's why my USB stick
works everywhere.

> What is the opposite paradigm? I don't care much about OO, I do about ADT.
> The real alternatives are typed vs untyped. I think we have been using the
> latter for too long and it won't stand up safety and quality requirements
> of future omnipresent computing.

I'm afraid that the omnipresent computing will bring us omnipresent
untypedness - or at least this is the current trend, if popularity of
programming languages is to be taken as any indication...

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Writing an Operating System in Ada

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1fhgwtz4ezt52.zvep41elk4lq.dlg@40tude.net...
> On Thu, 14 Jan 2010 13:07:08 -0800 (PST), Shark8 wrote:
...
>>> 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.
>>
>> I remember reading that now... but is an inheritance level of 1 good
>> enough?
>
> No, it is not. The bottom level is an interface, a quite useless thing
> because it does not provide implementation. The next level is a concrete
> implementation. The train stops there.

You're confusing inheritance of interfaces with inheritance of 
implementation. One of the most important parts of Ada is that it tries to 
strongly separate interfaces and implementation. [I know you know this 
difference, but are purposely ignoring it.]

You can have as much inheritance of interfaces as you want (as you showed in 
your read/write example).

Ada doesn't allow inheritance of implementation for synchronized objects, 
for the very good reason that no one knows how to make inheritance rules 
that doesn't violate the exclusion and ordering rules. We tried for a quite 
a while to make a version of inheritable protected types, but it always led 
to deadlocks, race conditions, or loss of exclusion. (Java has this problem 
in spades.)

We looked at some ideas for very limited inheritance, but it would have been 
quite complex. We didn't think anyone would understand the rules (they 
surely were not intuitive).

By not allowing inheritance at all, we keep all of the mutual exclusion in a 
single object where analysing it for problems is at least possible. Since 
subprogram calls are possible for the sequential code, it doesn't 
necessarily have to be duplicated (although most of the synchronized 
interface objects that we see are quite simple, as anything complex is 
pretty much a lost cause at the start).

Someday the state of the art might change; by not doing anything in Ada 2005 
we left open the possibility for doing it right (whatever that turns out to 
mean) in the future; had we done a lousy job in 2005, we couldn't have 
replaced it in the future without breaking a lot of existing code (which we 
won't do).

                               Randy.

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Thu, 14 Jan 2010 13:50:56 -0800 (PST), Maciej Sobczak wrote:

> On 14 Sty, 11:28, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> But I do not see how the OO approach would solve that problem. Plug
>>> the OO-aware drive from the OO-aware system from Microsoft into your
>>> OO-aware system of choice and you will be in the same mess.
>>
>> Sure. But your argument was that a file system would handle it better. It
>> does not.
> 
> The file system handles the data exchange between systems that were
> written with different paradigms in mind.
> Your objects would be transportable only between OO systems. That
> would be a huge portability limitation for me.

You can always serialize object. Call it a blob.

The problem is what do you do with the blob beyond undoubtedly enjoyable
moving it for one memory stick to another.

Because your file system has completely nothing to do with the contents,
there is neither any gain nor any loss.

> In this context, the advantage of the file system is that it does not
> impose any assumptions about the OS itself.

How so? It requires the file system to be implemented on each OS you wanted
to attach the device to.

> That's why my USB stick
> works everywhere.

No. It does not under MS-DOS. Did you try to write a movie file on a stick?
(FAT has limitations on the file size).

>> What is the opposite paradigm? I don't care much about OO, I do about ADT.
>> The real alternatives are typed vs untyped. I think we have been using the
>> latter for too long and it won't stand up safety and quality requirements
>> of future omnipresent computing.
> 
> I'm afraid that the omnipresent computing will bring us omnipresent
> untypedness - or at least this is the current trend, if popularity of
> programming languages is to be taken as any indication...

Is there an increase in the number of commercial projects done in those
languages?

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

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Thu, 14 Jan 2010 19:24:41 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1fhgwtz4ezt52.zvep41elk4lq.dlg@40tude.net...
>> On Thu, 14 Jan 2010 13:07:08 -0800 (PST), Shark8 wrote:
> ...
>>>> 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.
>>>
>>> I remember reading that now... but is an inheritance level of 1 good
>>> enough?
>>
>> No, it is not. The bottom level is an interface, a quite useless thing
>> because it does not provide implementation. The next level is a concrete
>> implementation. The train stops there.
> 
> You're confusing inheritance of interfaces with inheritance of 
> implementation. One of the most important parts of Ada is that it tries to 
> strongly separate interfaces and implementation. [I know you know this 
> difference, but are purposely ignoring it.]

I don't ignore it, I point out that interface inheritance requires no
interfaces (nor even abstract types). There is no problem to inherit the
interface of a concrete type.

Concerning separation of interface and implementation, I think that Ada
2005 interfaces in fact deviate from the model existing since Ada 83. In
Ada 83-95 the separation was never based on types. The separation then was
carried by packages. The programmer could choose between moving parts of
the implementation into private parts or else into the body. Incomplete
type declaration was the interface. It was simple, understandable, required
no extra up front work. Compared to this interfaces are complex, verbose
and superfluous. Yet they cannot replace the old model anyway, because
there are things like constants and bodies which are not types, yet have
implementations to separate.

> Ada doesn't allow inheritance of implementation for synchronized objects, 
> for the very good reason that no one knows how to make inheritance rules 
> that doesn't violate the exclusion and ordering rules. We tried for a quite 
> a while to make a version of inheritable protected types, but it always led 
> to deadlocks, race conditions, or loss of exclusion. (Java has this problem 
> in spades.)

Nobody says it will be simple...

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

Re: Writing an Operating System in Ada

[Maciej Sobczak]

On 15 Sty, 09:37, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> You can always serialize object. Call it a blob.

That's exactly what I'm doing right now - and that's why I do not see
any added value from pure-OO approach.

> The problem is what do you do with the blob beyond undoubtedly enjoyable
> moving it for one memory stick to another.

Nothing, because as long as the blob is on the stick, there is nothing
else I might want to do with it.
The blob becomes useful only when it is loaded into memory.

> Because your file system has completely nothing to do with the contents,
> there is neither any gain nor any loss.

The added value is that of name resolution. I can name my file (OK,
blob) as "my_homework_program.adb" and this intermediary naming layer
helps me with recognition of the content - otherwise I would have to
deal with sector numbers. The added value is exactly the same as that
of DNS, so that I do not have to type in the IP address of the
newsgroup service that I'm using right now.

The purpose of the file system is to bring understanding to the
digital mess and the current file systems do their job pretty well.

> > In this context, the advantage of the file system is that it does not
> > impose any assumptions about the OS itself.
>
> How so? It requires the file system to be implemented on each OS you wanted
> to attach the device to.

And the fact that my USB stick works everywhere shows that this
assumption is realistic. The assumption that the target OS is pure-OO
would not be.

> > That's why my USB stick
> > works everywhere.
>
> No. It does not under MS-DOS.

http://www.theinquirer.net/inquirer/news/1046069/yes-usb-drivers-dos
http://www.bootdisk.com/usb.htm
...

> Did you try to write a movie file on a stick?
> (FAT has limitations on the file size).

Which is completely unrelated to what we discuss.
(and lots of useful movies are short)

> > I'm afraid that the omnipresent computing will bring us omnipresent
> > untypedness - or at least this is the current trend, if popularity of
> > programming languages is to be taken as any indication...
>
> Is there an increase in the number of commercial projects done in those
> languages?

Are you sure you are still living in a world where
"commercial" (whatever that means) is equivalent to "leading"?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Fri, 15 Jan 2010 13:05:38 -0800 (PST), Maciej Sobczak wrote:

> On 15 Sty, 09:37, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> The problem is what do you do with the blob beyond undoubtedly enjoyable
>> moving it for one memory stick to another.
> 
> Nothing, because as long as the blob is on the stick, there is nothing
> else I might want to do with it.
> The blob becomes useful only when it is loaded into memory.

How does it?
 
>> Because your file system has completely nothing to do with the contents,
>> there is neither any gain nor any loss.
> 
> The added value is that of name resolution. I can name my file (OK,
> blob) as "my_homework_program.adb" and this intermediary naming layer
> helps me with recognition of the content - otherwise I would have to
> deal with sector numbers. The added value is exactly the same as that
> of DNS, so that I do not have to type in the IP address of the
> newsgroup service that I'm using right now.

You don't need names for something, which is useless. You said it is
useless when on the stick (which is of course wrong).

> The purpose of the file system is to bring understanding to the
> digital mess and the current file systems do their job pretty well.

Sorry, but I don't know which kind of understanding you mean. In any case,
"understanding" is not the purpose of the file system.

There are certain functionality a persistent store must provide. Among them
enumeration, efficient indexing, naming, notifications, journaling,
identification, distribution, authentication, consistency and so on. Modern
file systems is a persistent store that fulfills some of these
requirements. "Understanding" is not in this list.

>>> In this context, the advantage of the file system is that it does not
>>> impose any assumptions about the OS itself.
>>
>> How so? It requires the file system to be implemented on each OS you wanted
>> to attach the device to.
> 
> And the fact that my USB stick works everywhere shows that this
> assumption is realistic. The assumption that the target OS is pure-OO
> would not be.

Assumption? It is not an assumption, it is a fact, that somebody sat down
and wrote the implementation of FAT for the OS X1. Why he or someone else
could not do this for an OO X2 persistence layer?

>>> I'm afraid that the omnipresent computing will bring us omnipresent
>>> untypedness - or at least this is the current trend, if popularity of
>>> programming languages is to be taken as any indication...
>>
>> Is there an increase in the number of commercial projects done in those
>> languages?
> 
> Are you sure you are still living in a world where
> "commercial" (whatever that means) is equivalent to "leading"?

It is an equivalent to "measurable". You can measure involvement in serious
projects by investments in.

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

Re: Writing an Operating System in Ada

[nobody]

Shark8 wrote:
> On Jan 12, 3:39 pm, nobody <nob...@nowhere.com> wrote:
> 
>>Shark8 wrote:
>>
>>>The problem about having no I/O is that there are some file-formats
>>>which ARE sequential-in-nature as opposed to Random-access/Record-in-
>>>nature: Midi and Huffman encoding (actually MOST compression would
>>>fall here) are to examples off the top of my head. Or am I
>>>misunderstanding what you mean?
>>
>>That is just implementation details that should(can) be hidden from the
>>application code. Stick to the objects. Don't forget associations.
> 
> 
> Aren't associations rather trivial if we derive all files from some
> base tagged-type and use the tag as the type-identifier?

Only for -to one. But how about -to many and -to one or many or ....

For me associations are also almost always bidirectional.

So just a simple tag reference may not be enough and standardised ways 
to navigate would be great.

Re: Writing an Operating System in Ada

[Lucretia]

On Jan 13, 8:37 pm, Shark8 <onewingedsh...@gmail.com> wrote:

> Nifty. I came across your blog a while back as I was looking up some
> Ada 2005 features (thank you for your explanation, in particular);
> it's pretty good, IMO. If you'd like to pop me an e-mail or IM and
> talk-shop about OS/OS-design I'd be more than happy to do so. {The
> same goes for everyone else who's interested.}

I don't really use IM, feel free to drop by #Ada on Freenode tho :)

Luke.

Re: Writing an Operating System in Ada

[Maciej Sobczak]

On 15 Sty, 22:48, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > The blob becomes useful only when it is loaded into memory.
>
> How does it?

By becoming a typed entity that is referenced within the actively
executed program. This is the moment when blob becomes useful.

> > The added value is that of name resolution.

> You don't need names for something, which is useless. You said it is
> useless when on the stick (which is of course wrong).

Ah, so we are again at the discussion style that will lead us nowhere.
But let's try for a while.

Several posts ago you have requested to execute actions on objects.
"Play" was an action on the movie - you wanted that. When I said that
the blob (a file, essentially) becomes useful when it is loaded into
memory, I meant that it is the interpretation of the blob that gives
it some requested capabilities.
You want it to "Play", but I might want it to blur or sharpen instead.
The point is that I can blur or sharpen a "movie" thanks to the fact
that I see it at a different level that you wanted to see it and that
would not be possible with pure-OO approaches (unless you allow
Unchecked_Conversion, but that brings us back to blobs anyway).

> > The purpose of the file system is to bring understanding to the
> > digital mess and the current file systems do their job pretty well.
>
> Sorry, but I don't know which kind of understanding you mean.

Apparently you do not understand. :-)

> In any case,
> "understanding" is not the purpose of the file system.

Well, I use it for this purpose.

> There are certain functionality a persistent store must provide. Among them
> enumeration, efficient indexing, naming, notifications, journaling,
> identification, distribution, authentication, consistency and so on. Modern
> file systems is a persistent store that fulfills some of these
> requirements. "Understanding" is not in this list.

Because you did not put it on that list. I'm not going to discuss it
this way.

http://en.wikipedia.org/wiki/File_System

"file system is a method of storing and organizing computer files and
the data they contain to make it easy to find and access them"

For me, "organizing" and "easy to find" are two aspects of
"understanding what is on the drive". In any case, I understand what I
have on my drive.

> > And the fact that my USB stick works everywhere shows that this
> > assumption is realistic. The assumption that the target OS is pure-OO
> > would not be.
>
> Assumption? It is not an assumption, it is a fact, that somebody sat down
> and wrote the implementation of FAT for the OS X1. Why he or someone else
> could not do this for an OO X2 persistence layer?

The only way to implement any persistence layer across different OSs
is to have it not coupled to any OS. If you have pure-OO OS (that is,
when *everything* in this system is OO) then it's persistence layer
cannot be implemented on other, non-OO OSs.

Current file systems (the ones with blobs) serve well as "common
denominators" and this is exactly their value.

> > Are you sure you are still living in a world where
> > "commercial" (whatever that means) is equivalent to "leading"?
>
> It is an equivalent to "measurable". You can measure involvement in serious
> projects by investments in.

That's one approach. Another is to measure involvement by
participation. In the age of social-this, social-that and social-
whatever, the accounting is different.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Sat, 16 Jan 2010 13:18:46 -0800 (PST), Maciej Sobczak wrote:

> On 15 Sty, 22:48, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> The blob becomes useful only when it is loaded into memory.
>>
>> How does it?
> 
> By becoming a typed entity that is referenced within the actively
> executed program. This is the moment when blob becomes useful.

So the file containing a movie is useless?

> Several posts ago you have requested to execute actions on objects.
> "Play" was an action on the movie - you wanted that. When I said that
> the blob (a file, essentially) becomes useful when it is loaded into
> memory, I meant that it is the interpretation of the blob that gives
> it some requested capabilities.

Is there any player that loads movies into the memory? That must be a very
curious one. I also assume that data bases are all totally useless if their
contents do not fit into the memory? There still exist text editors capable
to handle files bigger than the virtual memory.

Note that your argument its bogus, because being logically continued, no
object is useful if not in the CPU cache. But, wait, those are useless too,
because not in the registers. Wait, no, they must be on the wire in the CPU
to be useful.

>> In any case,
>> "understanding" is not the purpose of the file system.
> 
> Well, I use it for this purpose.

Others uses microscopes to crack nuts...

>> There are certain functionality a persistent store must provide. Among them
>> enumeration, efficient indexing, naming, notifications, journaling,
>> identification, distribution, authentication, consistency and so on. Modern
>> file systems is a persistent store that fulfills some of these
>> requirements. "Understanding" is not in this list.
> 
> Because you did not put it on that list. I'm not going to discuss it
> this way.
>
> http://en.wikipedia.org/wiki/File_System
> 
> "file system is a method of storing and organizing computer files and
> the data they contain to make it easy to find and access them"

System is a method? (:-)) That sort of definition does not deserve to be
discussed.

>>> And the fact that my USB stick works everywhere shows that this
>>> assumption is realistic. The assumption that the target OS is pure-OO
>>> would not be.
>>
>> Assumption? It is not an assumption, it is a fact, that somebody sat down
>> and wrote the implementation of FAT for the OS X1. Why he or someone else
>> could not do this for an OO X2 persistence layer?
> 
> The only way to implement any persistence layer across different OSs
> is to have it not coupled to any OS.

I cannot comment on that, because I don't know the meaning of the word
"coupled" you are using here.

> If you have pure-OO OS (that is,
> when *everything* in this system is OO) then it's persistence layer
> cannot be implemented on other, non-OO OSs.

That is a logical fallacy:

   X has no A AND X has A => X is not X

X=OS, A=OO. Yes, if the OS is defined as not supporting persistent objects,
then no OS can support them.

> Current file systems (the ones with blobs) serve well as "common
> denominators" and this is exactly their value.

And the unicycle is the common denominator of all vehicles, therefore cars
with four wheels are useless...

>>> Are you sure you are still living in a world where
>>> "commercial" (whatever that means) is equivalent to "leading"?
>>
>> It is an equivalent to "measurable". You can measure involvement in serious
>> projects by investments in.
> 
> That's one approach. Another is to measure involvement by
> participation. In the age of social-this, social-that and social-
> whatever, the accounting is different.

I must disappoint you. That measurement was used first in the age of
slavery, when the time assigned to the activity (then performed by slaves)
was the measure. This measure is quite poor because workers are different
and activities are too. This is why slavery, corv�e, socialized economies
gave way to the free market ones. One can use that "different" accounting
to fool others, but better not oneself.

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

Re: Writing an Operating System in Ada

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:
> On Sat, 16 Jan 2010 13:18:46 -0800 (PST), Maciej Sobczak wrote:
> 
>> On 15 Sty, 22:48, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>> wrote:
>>
>>>> The blob becomes useful only when it is loaded into memory.
>>> How does it?
>> By becoming a typed entity that is referenced within the actively
>> executed program. This is the moment when blob becomes useful.
> 
> So the file containing a movie is useless?
> 
>> Several posts ago you have requested to execute actions on objects.
>> "Play" was an action on the movie - you wanted that. When I said that
>> the blob (a file, essentially) becomes useful when it is loaded into
>> memory, I meant that it is the interpretation of the blob that gives
>> it some requested capabilities.
> 
> Is there any player that loads movies into the memory?

This topic is rather interesting considering languages' I/O
sections. So its dicussion will profit from keeping it
technical. (The obvious idea here is that naggy remarks about
some presumed meaning of "load" could be more lucid.)
If there is a misunderstanding, please help:
in a world of existing separate OSs, or of to be
designed OSs, would their respective persistence layers allow,
given the identifier of some object,

(1) calling primitive subs defined with the object's type T

(2) learning about T's subs in case the object was stored
    by some program (defining T) not known to the caller,

(3) adding subs to T to accomodate specified processing needs
    of another, later program? How?

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Mon, 18 Jan 2010 12:23:23 +0100, Georg Bauhaus wrote:

> If there is a misunderstanding, please help:
> in a world of existing separate OSs, or of to be
> designed OSs, would their respective persistence layers allow,
> given the identifier of some object,

Identifier of some object = the object itself, like when you write in Ada:

    X : Integer;

X is the object and an identifier of.
 
> (1) calling primitive subs defined with the object's type T

Certainly.
 
> (2) learning about T's subs in case the object was stored
>     by some program (defining T) not known to the caller,

No, you don't have the object then (object = identity + type + value).
First you have to convert the type of the object and get a view or else
another transient object of the desired type. Ada's equivalent:

   X : T'Class;
begin
   ... S (X) ...  -- S is a member of T'Class

You might also be able to check if X in S'Class etc.

> (3) adding subs to T to accomodate specified processing needs
>     of another, later program? How?

By conversion of the object to another type:

   X : Integer;
   Y : Float := Float (X); -- Now we have sin, cos etc

This conversion might happen to be a view conversion or not.

1,2,3 represent no problem. IMO the real challenge (apart from consistent
implementations of MI and MD) are dynamic types marshaled between the parts
of a distributed system. I didn't think much about that, so don't expect me
to answer how that should be solved. Probably others might have some
insights...

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

Re: Writing an Operating System in Ada

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:
> On Mon, 18 Jan 2010 12:23:23 +0100, Georg Bauhaus wrote:
> 
>> If there is a misunderstanding, please help:
>> in a world of existing separate OSs, or of to be
>> designed OSs, would their respective persistence layers allow,
>> given the identifier of some object,
> 
> Identifier of some object = the object itself, like when you write in Ada:
> 
>     X : Integer;
> 
> X is the object and an identifier of.
>  
>> (1) calling primitive subs defined with the object's type T
> 
> Certainly.
>  
>> (2) learning about T's subs in case the object was stored
>>     by some program (defining T) not known to the caller,
> 
> No, you don't have the object then (object = identity + type + value).
> First you have to convert the type of the object and get a view or else
> another transient object of the desired type. Ada's equivalent:
> 
>    X : T'Class;
> begin
>    ... S (X) ...  -- S is a member of T'Class
> 
> You might also be able to check if X in S'Class etc.
> 
>> (3) adding subs to T to accomodate specified processing needs
>>     of another, later program? How?
> 
> By conversion of the object to another type:
> 
>    X : Integer;
>    Y : Float := Float (X); -- Now we have sin, cos etc

This conversion of a (then) persistent Integer object
to a Float object is possible because either type is known
(and can be named). The meaning of conversion from Integer
to Float is language defined, too.
That is, either object's type is known in the program storing
X as an Integer and in the program processing X as a Float,
respectively.
In particular, the second program "knows" about the possibility
of conversion of known type Integer to known type Float.

What a persistent O-O storage would have to offer is something
in addition.

In Toulouse:

  X : Private_Type_A;
begin
  OO_Store.Put(X);
end;

Then, where Identity is an identifier, or the object, or
a handle, or a filename, or ...:

Pass(Identity(X), From => Toulouse, To => Hamburg);

In Hamburg:

  Y : Private_Type_B;
begin
  OO_Store.Get(Y [, <from the identity>]);

How is Hamburg enabled to learn what Toulouse.Private_Type_A
is with the persistence layer functioning as the only source of
information about the object?  Which operations does it support?
What kind of conversions are possible, what granularity of
access to the object's innards might be needed to reify
the interface of Hamburg.Private_Type_B?

I see a hole there that needs to be filled. Indeed:

> IMO the real challenge (apart from consistent
> implementations of MI and MD) are dynamic types marshaled between the parts
> of a distributed system. I didn't think much about that, so don't expect me
> to answer how that should be solved. Probably others might have some
> insights...

I guess this challenge is what some here had hoped to learn
about. You sounded like you knew the solution :-)

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Mon, 18 Jan 2010 16:21:53 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
>> On Mon, 18 Jan 2010 12:23:23 +0100, Georg Bauhaus wrote:
>> 
>>> (3) adding subs to T to accomodate specified processing needs
>>>     of another, later program? How?
>> 
>> By conversion of the object to another type:
>> 
>>    X : Integer;
>>    Y : Float := Float (X); -- Now we have sin, cos etc
> 
> This conversion of a (then) persistent Integer object
> to a Float object is possible because either type is known
> (and can be named).

You cannot have object of an unknown type.

> The meaning of conversion from Integer
> to Float is language defined, too.

Type-defined. Conversion of concrete types is a doubly-dispatching
primitive operation. Ada 83 didn't have dispatching operations and MD is
still 

> What a persistent O-O storage would have to offer is something
> in addition.
> 
> In Toulouse:
> 
>   X : Private_Type_A;
> begin
>   OO_Store.Put(X);
> end;

Put (OO_Store, "Some name", X);

I prefer this notation, because this operation also is doubly-dispatching.
 
> Then, where Identity is an identifier, or the object, or
> a handle, or a filename, or ...:
> 
> Pass(Identity(X), From => Toulouse, To => Hamburg);

Rather:

Put (OO_Store, Locate ("Hamburg") & "Some name", X);

you do not need to pass anything. Store it where it belongs to. The main
idea is that imperative I/O is normally not needed. "Pass" is disguised
I/O.

> In Hamburg:
> 
>   Y : Private_Type_B;
> begin
>   OO_Store.Get(Y [, <from the identity>]);
> 
> How is Hamburg enabled to learn what Toulouse.Private_Type_A
> is with the persistence layer functioning as the only source of
> information about the object?

In this case from some information outside:

   Y : Interested_In'Class := Get (OO_Store, "Some name");

> Which operations does it support?

Of the class. When you create Y in your program you know what you are going
to do with it. That is described by Interested_In. This is no different
from knowing its name "Some name". This is a-priori knowledge. For example,
a compiler expects an Ada source file.

> What kind of conversions are possible, what granularity of
> access to the object's innards might be needed to reify
> the interface of Hamburg.Private_Type_B?

There is a common ancestor for both types. What you probably had in mind
was a conversion is between types from independent hierarchies rooted on
different hosts. That normally should not be needed.

To me the problem rather is in passing the concrete type of Y, which the
program will never have to learn, but the run-time must. It will modify the
dispatching tables, take the implementations of overridden operations in
the form of some byte code (?) etc.

>> IMO the real challenge (apart from consistent
>> implementations of MI and MD) are dynamic types marshaled between the parts
>> of a distributed system. I didn't think much about that, so don't expect me
>> to answer how that should be solved. Probably others might have some
>> insights...
> 
> I guess this challenge is what some here had hoped to learn
> about. You sounded like you knew the solution :-)

I am sorry, then. There are hundreds of well paid people sitting in
universities studying and teaching OS'es and distributed systems. Why are
you asking me? Ask Andy Tannenbaum! (:-))

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

Re: Writing an Operating System in Ada

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:

> There is a common ancestor for both types. What you probably had in mind
> was a conversion is between types from independent hierarchies rooted on
> different hosts. That normally should not be needed.

Well, I learned from the discussion that independent roots of
blobs' types it is a quite common case.
In fact, it is the very cases on which the objections were based.

> To me the problem rather is in passing the concrete type of Y, which the
> program will never have to learn, but the run-time must. It will modify the
> dispatching tables, take the implementations of overridden operations in
> the form of some byte code (?) etc.

Right.  The modifiable dispatching tables are the
interesting part or an O-O file system. I guess that CORBA and
Microsoft CORBA (.NET) may offer some hints.

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Mon, 18 Jan 2010 18:17:20 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
> 
>> There is a common ancestor for both types. What you probably had in mind
>> was a conversion is between types from independent hierarchies rooted on
>> different hosts. That normally should not be needed.
> 
> Well, I learned from the discussion that independent roots of
> blobs' types it is a quite common case.

No. It is rather like

Node A:  Numeric_Type <-- A_Integer_Type
              ||
Node B:  Numeric_Type <-- B_Integer_Type (implementation)

B_Integer_Type is an invisible ad-hoc implementation of A_Integer_Type.
Node B uses the object from A as Numeric_Type'Class known to both nodes.

If some type is unknown to B, there is no way to write a program in terms
of this type. If you had a program for some unrelated type, you could not
convert any object to this type. It would be a type error.

An ability for example to convert Float to Integer is based on their
relationship, each can be considered a subtype of another. This
relationship is given, known on each node. It is possible to introduce
ad-hoc subtypes, but then it is the programmer's responsibility to provide
conversions, because there is no way to deduce them. This is the reason why
a powerful type system is needed. You will need to describe richer
relationships between types than contemporary OOPL can. Without these
relationships the system would become unusable or else degrade to the
low-level read/write interfaces.

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

Re: Writing an Operating System in Ada - now off topic?

[Leslie]

Maciej Sobczak wrote:

> On 12 Sty, 20:56, "Dmitry A. Kazakov"
> <mail...@dmitry-kazakov.de> wrote:
> 
>> There should be no file system at all. If you have objects, I
>> mean if you do have them consistently all the way, then you do
>> not need files. Make objects persistent in the corresponding
>> device, that gives you all functionality of any file. No I/O
>> is ever needed. Map the object into the memory, call its
>> operations, what else any program would have to do?
> 
> Interact with other systems? You know, you might want to
> sometimes move your "persistent objects" to another machine.
> 
> Did I mention that you might want to move you whole hard drive
> to another machine as well? :-)
> 
> There is a reason why none of the
> pure-OO-OS-let's-do-it-correctly ever really took off.
> 
>> The problem is that we followed the wrong path for too long.
> 
> There is nothing wrong with that path, as it happens to be very
> pragmatic.
> 
> --
> Maciej Sobczak * www.msobczak.com * www.inspirel.com
> 
> Database Access Library for Ada: www.inspirel.com/soci-ada

        I think it's time to rename this thread. :-)
Leslie

Re: Writing an Operating System in Ada

[Shark8]

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

So, what's wrong with it being used as a data-carrier? Like I
mentioned before, it would be a nice uniform (and incidentally
hardware-independent) data-carrier. It's not unfeasible to assume that
it would make for some good low-bandwidth remote-UI as well, as
opposed to X where the whole display is sent at every update (like a
mouse-move/cursor-redraw update). And that it would be "unusable for
humans" is a bit of a red-herring; X's data-link is even MORE unusable
for humans and yet it is a fairly popular method for remote-desktop.

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

What do you think of [Delphi-style] properties then? Basically they're
an specification of some [virtual] field of an object [with indicators
of it being readable and/or writable] that may either be renaming some
internal field OR the appropriate getter/setter for a field in the
implementation. I rather like the idea because it doesn't pollute the
object-space with so many [publicly visible] getter/setter methods.

Just to make sure there's no misunderstanding of what I'm referring
to, here's the Delphi code for some person:

Type
TPerson = class
 private
  FFName, FMName, FLName : ShortString; {Internal Fields for first,
middle, and last names.}
  FAge : Byte;

  Function FullName: String;
  Procedure Set_FName( Value: ShortString );    {Setter for fires
name.}
  Procedure Set_FLame( Value: ShortString );
 public
  Name : String read FullName;                             {Military
Format; ex: Smith, John Q.      }
  First_Name  : ShortString read FFName write Set_FName;   {Setter
disallows zero-length first names.}
  Middle_Name : ShortString read FMName write    FMName;   {Zero-
length middle names are allowed.    }
  Last_Name   : ShortString read FLName write Set_LName;   {Setter
disallows zero-length last names. }
  Age         : Byte write FAge;                           {Write-only
for this application/object...}
 end; {TPerson}


IMPLEMENTATION

  Procedure TPerson.Set_FName( Value: ShortString );
   begin
    IF Length(Value) > 0 THEN FFName:= Value;
   end;

  Procedure TPerson.Set_FLame( Value: ShortString );
   begin
    IF Length(Value) > 0 THEN FLName:= Value;
   end;

  Function FullName: String;
    Middle_Initial : Character:= #000; {Null initial-value}
   begin
     IF Length(FMName) > 0 THEN Middle_Initial:= FMName[1]; {Get First
Character.}
     FullName:= Last_Name + ', ' + First_Name + ' ' + Middle_Initial
   end;

Re: Writing an Operating System in Ada

[Shark8]

On Jan 14, 12:04 pm, tmo...@acm.org wrote:
> > > 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.
>
>   The desktop on my computer rarely looks similar to a piece of paper on
> my real desk.  I doubt Postscript is an equally good description language
> for both.  Didn't the Next computer use Postscript?  And do current Macs?

That's incorrect, insofar as the hardware [your monitor] is concerned
your computer's desktop is EXACTLY like a piece of paper, or rather
multiple ones drawn and shown to you. For example VCR tapes run at 25
FPS, this is exactly the same as taking some twenty-five drawn frames
and showing them over one second.

PostScript is perfectly suitable for drawing such a frame. In fact, if
you program things as being based off of vectors and shadings
{something PS is GOOD at} then it's conceivable that your desktop
could be independent [some caveats on low-resolutions, obviously] of
resolution/color-depth keeping things relatively uniform. Just like
you can use a PS file to print a good-looking big poster and use the
same file to print an [equivalent] 8.5x11 poster/thumbnail.

Re: Writing an Operating System in Ada

[Dmitry A. Kazakov]

On Tue, 19 Jan 2010 10:58:23 -0800 (PST), Shark8 wrote:

>>> 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? (:-))
> 
> So, what's wrong with it being used as a data-carrier?

Nothing, except that there could be better ones and it is uninteresting for
the programmer even to know what is actually used as the carrier.

>>>> 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.
> 
> What do you think of [Delphi-style] properties then? Basically they're
> an specification of some [virtual] field of an object [with indicators
> of it being readable and/or writable] that may either be renaming some
> internal field OR the appropriate getter/setter for a field in the
> implementation. I rather like the idea because it doesn't pollute the
> object-space with so many [publicly visible] getter/setter methods.

This is OK, but unrelated to MI. It about separation of implementation and
specification, which was not accomplished in Ada with respect to fields.
Operations of accessing members should be a primitive. What is visible as a
field should be possible to implement either as a physical field or as
getter/setter operations. MI is independent on this. It is about membership
in more than one disjoint classes. Interface is poor-man's MI, restricted
so some artificially chosen cases, which still do not save from either of
non-existent MI problems.

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

Re: Writing an Operating System in Ada

[Shark8]

> > Aren't associations rather trivial if we derive all files from some
> > base tagged-type and use the tag as the type-identifier?
>
> Only for -to one. But how about -to many and -to one or many or ....
>
> For me associations are also almost always bidirectional.
>
> So just a simple tag reference may not be enough and standardised ways
> to navigate would be great.

Good catch. There are several case that we need to be aware of:
programs/operations that can take such a file as input, that produces
such as output, AND the DEFAULT[s]. This could be done with a registry
[database, relational] that tracks the associations.