Ada OS based on Minix3

Ada OS based on Minix3

[Cedric.Lannock]

Hi all,

I came across Ada at the beginning of the year and read quite a few
books about Ada. A few month later I joined a Linux workgroup within a
local computer association. This way I learned about Ada and had a
look into Tanenbaum's book on operating systems (http://www.amazon.com/
Operating-Systems-Implementation-Prentice-Software/dp/0131429388/
ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1226066518&sr=8-1) and Minix 3
(http://www.minix3.org/).

I thought about an operating system written fully in Ada. When surfing
the net I came across the various discussions about that subject.

What taking the Minix 3 system as basis for porting it to Ada? The
Minix 3 is a modern micro kernel os and has about 4.000 Lines of code.
It is full Posix compatible. Some guys have added real time
functionality to it (see ACM.org for further reading). Thus it would a
good place to start. As it has to few lines of code it should be
possible to build a kernel in overseeable time.

Another thought to get this project taking some speed would be not to
rewrite all the available C code but to develop a translator c2ada. It
would us getting startet and the resulting code could be enhanced and
improved.

Do you think this would make this project doable?

Regards

Cedric Lannock

Re: Ada OS based on Minix3

[xavier grave]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cedric.Lannock a �crit :
> Hi all,
> 
> I came across Ada at the beginning of the year and read quite a few
> books about Ada. A few month later I joined a Linux workgroup within a
> local computer association. This way I learned about Ada and had a
> look into Tanenbaum's book on operating systems (http://www.amazon.com/
> Operating-Systems-Implementation-Prentice-Software/dp/0131429388/
> ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1226066518&sr=8-1) and Minix 3
> (http://www.minix3.org/).
> 
> I thought about an operating system written fully in Ada. When surfing
> the net I came across the various discussions about that subject.
> 
> What taking the Minix 3 system as basis for porting it to Ada? The
> Minix 3 is a modern micro kernel os and has about 4.000 Lines of code.
> It is full Posix compatible. Some guys have added real time
> functionality to it (see ACM.org for further reading). Thus it would a
> good place to start. As it has to few lines of code it should be
> possible to build a kernel in overseeable time.
> 
> Another thought to get this project taking some speed would be not to
> rewrite all the available C code but to develop a translator c2ada. It
> would us getting startet and the resulting code could be enhanced and
> improved.
> 
> Do you think this would make this project doable?
> 
> Regards
> 
> Cedric Lannock


Hi Cedric,

I have started to develop some kind of OS fully in Ada : Lovelace.

I have thought recently to restart all of it on a minix3 basis, but the
lack of Virtual Memory handling stopped me (as far as I understood
minix3) and also that minix has is proper compiler which isn't gcc. And
something I definitively don't want to do is to write an Ada compiler to
produce minix binary format. Perhaps adapt GNAT to minix is a reseanable
 project but it doesn't seem so to me.

If you want we can try to join our forces for building a fully Ada OS.

Cordially, xavier
PS:
My work is mainly a translation from C to Ada of the SOS work[1].
This isn't a strict translation and for example exception support is
enabled from the very beginning of the kernel boot (ease a lot the
kernel debugging).

Here is a monotone repository with the last lovelace code : [2].
For more information about accessing this monotone server : [3].

There is already some Ada OS available like MarteOS (not full Ada code
as far as I understand, list of Ada OS not exhaustive).

[1]http://sos.enix.org/en/MainPage
[2]http://www.ada-france.org:8081/branch/changes/org.os-lovelace
[3]http://www.ada-france.org/article131.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkUas0ACgkQVIZi0A5BZF58HQCffCisIi0ogUk4QMrFqtyvUrLf
npQAn24u86fEg05jhEl/FDDu1zV2SkAA
=i1AY
-----END PGP SIGNATURE-----

Re: Ada OS based on Minix3

[anon]

There are a number of Ada OSs like that are Posix based: 
(All based on GNAT Ada)
	"Lovelace" by xavier grave (active project)
	MaRTE project (still activity)
	RTEMS project

For a kernel completely written in Ada may be an idea, but in today's world 
it might be hard to do.  A lot of kernel authors use GNAT, but GNAT was not 
designed to create stand-alone bootable code. And with GCC not fully 
supporting 16-bit code generation, GNAT can not fully generate a Legacy 
bootable code. But there may be hope, do to newer motherboards using newer 
BIOS based on INTEL EFI specs, like the AMIBIOS with Aptio EFI Firmware.  
These new BIOSs asap switch the processing mode to Protected-Mode then 
boot the OS as an 32 or 64 bit protected-mode application. Plus, 
protected-mode hardware device drivers can be loaded in a Flash device 
driver BIOS area. 

For older motherboard, one might try CoreBoot aka LinuxBIOS. But for now 
most people just use the GRUB boot loader which is written in C and that 
kind of defect the concept of 100% Ada OS. So, it might be take some time 
to see a true 100% kernel.

Note: ASUS, INTEL and others are schedule to use the new AMI Protected-Mode 
BIOS in the second/third quarters of 2008. Which means that someone should 
be able to write a multi-functional boot loader completely in Ada and then
the kernel in 100% Ada code for some.  But changing out all of the Legacy 
based BIOS or upgrade motherboards will still take a long time.

Now, I have written a couple of Ada (MBR) (Intel based) boot loaders using 
GNAT using gcc 3.2 that can boot an Ada kernel from either a floppy or 
bootable CD. It can be done using GNAT 2007 but the process is more involved.

Also at the movement I prefer nonposix design. Plus there is some talk that
the EFI Firmware spec may replace some of the POSIX spec. Plus, to me why, 
reinvent the wheel aka another Posix OS. Those who start to write an Ada OS 
kernel should prove that Ada is better by showing there is a better interface 
than just another Posix.  Maybe calling it Aside (Ada Operating System 
Interface) which could include a posix addon module.  This posix module 
could be use as a less secure interfere to existing non Ada software. But 
for the true ability of the Ada OS then an application would be needed to 
be written in Ada using Aosix.

And as for "c2ada" there is a couple of projects that do work, but they are at 
the movement limited to either Ada 83 or Ada 95 specs.  But with the Posix 
add on module to an Ada OS that would allow C code to be use, once the 
kernel and base apps are written in Ada.

As for using Minix 3 as a base for the an Ada OS.  If you borrow a routine or 
two that's OK, but to base a complete design on anyone else's work is just a 
type of plagiarism, that I am not into.  And you only prove that the original 
author could of used Ada, but not that Ada is better for writing an OS. Or that 
an Ada OS can stand on it on merits. The best why is to create a totally new 
design that take the best concepts from a majority of OS and try to limit the 
worst concepts that those OS have.


In <ed7d1ea9-bf0b-4e4a-b317-b57102853d65@p35g2000prm.googlegroups.com>, "Cedric.Lannock" <Cedric.Lannock@gmx.net> writes:
>Hi all,
>
>I came across Ada at the beginning of the year and read quite a few
>books about Ada. A few month later I joined a Linux workgroup within a
>local computer association. This way I learned about Ada and had a
>look into Tanenbaum's book on operating systems (http://www.amazon.com/
>Operating-Systems-Implementation-Prentice-Software/dp/0131429388/
>ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1226066518&sr=8-1) and Minix 3
>(http://www.minix3.org/).
>
>I thought about an operating system written fully in Ada. When surfing
>the net I came across the various discussions about that subject.
>
>What taking the Minix 3 system as basis for porting it to Ada? The
>Minix 3 is a modern micro kernel os and has about 4.000 Lines of code.
>It is full Posix compatible. Some guys have added real time
>functionality to it (see ACM.org for further reading). Thus it would a
>good place to start. As it has to few lines of code it should be
>possible to build a kernel in overseeable time.
>
>Another thought to get this project taking some speed would be not to
>rewrite all the available C code but to develop a translator c2ada. It
>would us getting startet and the resulting code could be enhanced and
>improved.
>
>Do you think this would make this project doable?
>
>Regards
>
>Cedric Lannock

Re: Ada OS based on Minix3

[Ivan Levashew]

Cedric Lannock wrote:

> As it has to few lines of code it should be
> possible to build a kernel in overseeable time.

Kernel isn't enough. Drivers, applications. And, the most essential
thing, users' and developers' awareness, what's wrong with other OSes;
what's wrong with GNU, Microsoft and Apple.

I'm wondering what you're trying to achieve with Ada OS? Is it just a
casting tech skills?

Two general problems of starting an enterprise Ada project are as
follows:
Lack of libraries
Lack of developers

While you can do little about the second, you can at least do binding
generators. There are 2 unfinished ones: GNATCOM and GNAT-SWIG.

GNATCOM is part of GNAVI project. GNAVI was quite popular several
years ago.
GNATCOM fails to compile on latest GNAT (Ada 2005). I have succeded in
making it running and created a demo Delphi+Ada webserver using it.
One need to delete "-gnatg" option out of GNATCOM Makefiles and rename
GNATCOM.Interface package to another name, e. g. COM_Interface. It
will at least be working, but still not convenient to use (due to
thinness of data types, e. g. one has to write Issue.Attach
(DB_Access.Get_Issue); Rubrics.Attach (Issue.Get_Rubrics); instead of
DB_Access.Issue.Rubrics). GNATCOM doesn't claim to be thick binding
generator after all.

Another unfinished stuff is GNAT-SWIG. It was started in 2006, when
Ada 2005 implementation wasn't stable and complete. An essential thing
like GNAT-SWIG should feel like Ada 2005, so it might need to be
changed as well.


Or, if you want to start from scratch, you have an option to make
binding generator for XPCOM and UNO (OpenOffice.org). First will give
a good crossplatform UI. Starting from v1.9, Gecko finally got Mac OS
X right, and it's currently AFAIK the only UI engine that feels native
on every OS.

UNO bindings will enable Ada applications to portably manage Office
documents.

The work to be done is as hardcore as writing OS, yet indeed much more
people would benefit from it.

I don't think that something 100% Ada is a good idea because nowadays
lorry number of such projects is very small.

>
> Another thought to get this project taking some speed would be not to
> rewrite all the available C code but to develop a translator c2ada. It
> would us getting startet and the resulting code could be enhanced and
> improved.
>
I have a better idea: first, manually convert C code to Cyclone code
(that's what Cyclone is really good for). Then it could be more easily
translated into Ada code.

Re: Ada OS based on Minix3

[Dmitry A. Kazakov]

On Mon, 10 Nov 2008 00:12:10 -0800 (PST), Ivan Levashew wrote:

> Two general problems of starting an enterprise Ada project are as
> follows:

> Lack of libraries
> Lack of developers

First of all, lack of ideas.

It makes no sense to make yet another linux.

In my opinion an Ada OS, if there should be one, must be fully OO and have
native Ada interface. In order to achieve this, much has to be done at the
language level first. An OO OS is unthinkable without MI, MD and safe
(non-cooperative) tasks and protected objects.

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

Re: Ada OS based on Minix3

[Ivan Levashew]

> First of all, lack of ideas.

I don't think an idea will help much. IMHO currently dirty work
matters. IDE integration plugins, protocol implementations. Scripting
languages extension toolkits. Tutorials.

Re: Ada OS based on Minix3

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:

> It makes no sense to make yet another linux.

This is a reason for suggesting Minix which
is---and was---not another Linux.

Re: Ada OS based on Minix3

[Jacob Sparre Andersen]

Dmitry A. Kazakov wrote:

> It makes no sense to make yet another linux.

In a way, I agree.  But at the same time, I like to have the freedom
to choose among several different, free/Open Source, POSIX compliant
operating systems.

> In my opinion an Ada OS, if there should be one, must be fully OO
> and have native Ada interface.

Why should it necessarily be object oriented?

I think the important part in writing an operating system is to figure
out how you can do it "better".  If we want to write an operating
system in Ada, we should consider how we can make a "better" operating
system using that.  It seems that "better" in this case is
reliability, maintenance and efficiency.  I am not sure if this is
done best using "full OO" or not.

Personally I appreciate standards compliance, so I would probably
include a POSIX API on the feature list.

> In order to achieve this, much has to be done at the language level
> first.

In the sense that the language should be changed?  (Would it still be
Ada then? :-)

Greetings,

Jacob
-- 
"Genes don't matter. It's all physics."

Re: Ada OS based on Minix3

[Dmitry A. Kazakov]

On 10 Nov 2008 11:24:58 +0100, Jacob Sparre Andersen wrote:

> Dmitry A. Kazakov wrote:
> 
>> It makes no sense to make yet another linux.
> 
> In a way, I agree.  But at the same time, I like to have the freedom
> to choose among several different, free/Open Source, POSIX compliant
> operating systems.

Freedom of choice assumes diversity. There is not much diversity in what is
called "modern" OSes. In recent time worked mainly with Windows, Linux,
VxWorks (before that I did with Sys V, VMS, Solaris). I just don't consider
them conceptually different. IMO it makes no sense to have another one like
these.

>> In my opinion an Ada OS, if there should be one, must be fully OO
>> and have native Ada interface.
> 
> Why should it necessarily be object oriented?

Because otherwise OS is damned to have a very low-level interface. The sad
consequence of this are poorly integrated OS-like additional storeys with a
huge overhead due to interface impedance. DBMS is one notorious example.
Others are numerous middlewares like CORBA etc. This architecture has no
future, IMO.

> I think the important part in writing an operating system is to figure
> out how you can do it "better".  If we want to write an operating
> system in Ada, we should consider how we can make a "better" operating
> system using that.  It seems that "better" in this case is
> reliability, maintenance and efficiency.

Yes, but note, you were talking about *non-functional* requirements, here.
It is placing a cart before the horse.

> I am not sure if this is
> done best using "full OO" or not.

OO is not a tool here, it is a goal, a *functional* requirement. Others are
to have it embeddable, heterogeneous, distributed, with persistent objects.

> Personally I appreciate standards compliance, so I would probably
> include a POSIX API on the feature list.

POSIX is on the top of the list ... of thing to scrap ...

>> In order to achieve this, much has to be done at the language level
>> first.
> 
> In the sense that the language should be changed?  (Would it still be
> Ada then? :-)

Sure. Ada means "designed to support the construction of long-lived, highly
reliable software systems" ARM 1/1.

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

Re: Ada OS based on Minix3

[Ludovic Brenta]

Ivan and Dmitry, you are discussing the viability of an operating
system written in Ada but, I think, you are missing the OP's point.
Cedric does not seem to care whether there is a market opportunity or
what breakthrough technology he might want to introduce; he wants to
learn kernel design (from Tanenbaum) and Ada (from various books and
us). Yes, he would be reinventing the wheel. But in this process he
could become a master wheel-builder just like one Linus Torvalds
before him. Sometimes, "reinventing" is precisely the goal. If nobody
ever "reinvented", then nobody would learn to "invent" new things.

So, Cedric, I encourage you to pursue this idea of yours. Lovelace is
still small enough to be comprehensible by a single person, so, if you
would like to work with other people and receive feedback, joining
forces with Xavier Grave on this project is a good idea.

--
Ludovic Brenta.

Re: Ada OS based on Minix3

[Ivan Levashew]

Ludovic Brenta wrote:

> Ivan and Dmitry, you are discussing the viability of an operating
> system written in Ada but, I think, you are missing the OP's point.
> Cedric does not seem to care whether there is a market opportunity or
> what breakthrough technology he might want to introduce; he wants to
> learn kernel design (from Tanenbaum) and Ada (from various books and
> us). Yes, he would be reinventing the wheel.

I'm not against wheels. I'm against projects with small lorry number.
There are lots of collecting dust.

Re: Ada OS based on Minix3

[Ludovic Brenta]

Ivan Levashew wrote:
> I'm not against wheels. I'm against projects with small lorry number.
> There are lots of collecting dust.

What is a "small lorry number" ?

--
Ludovic Brenta.

Re: Ada OS based on Minix3

[Robert A Duff]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Ivan and Dmitry, you are discussing the viability of an operating
> system written in Ada but, I think, you are missing the OP's point.
> Cedric does not seem to care whether there is a market opportunity or
> what breakthrough technology he might want to introduce; he wants to
> learn kernel design (from Tanenbaum) and Ada (from various books and
> us).

All the more reason to do something "new" and "interesting", rather than
cloning the posix "wheel".

Nothing wrong with taking inspiration from Minix/Tanenbaum,
but for a hobby project, why not try out some new ideas as well?

>... Yes, he would be reinventing the wheel. But in this process he
> could become a master wheel-builder just like one Linus Torvalds
> before him. Sometimes, "reinventing" is precisely the goal. If nobody
> ever "reinvented", then nobody would learn to "invent" new things.
>
> So, Cedric, I encourage you to pursue this idea of yours. Lovelace is
> still small enough to be comprehensible by a single person, so, if you
> would like to work with other people and receive feedback, joining
> forces with Xavier Grave on this project is a good idea.

- Bob

Re: Ada OS based on Minix3

[Ivan Levashew]

>
> Nothing wrong with taking inspiration from Minix/Tanenbaum,
> but for a hobby project, why not try out some new ideas as well?
>
E.g. choose Plan9 instead of Minix3. Plan9 ideas can still be
considered novel.

Re: Ada OS based on Minix3

[Ivan Levashew]

> In my opinion an Ada OS, if there should be one, must be fully OO and have
> native Ada interface.

Which is unthinkable without Ada ABI. I'm missing Dylan's "sealed/
unsealed".

> An OO OS is unthinkable without MI, MD and safe
> (non-cooperative) tasks and protected objects.

What PL family do you mean:
Sather/Eiffel, C++, Dylan/CLOS?

BTW, in '88 or so there existed an OO-extension for Ada. It was called
InnovAda.

Re: Ada OS based on Minix3

[Dmitry A. Kazakov]

On Mon, 10 Nov 2008 02:50:22 -0800 (PST), Ivan Levashew wrote:

>> In my opinion an Ada OS, if there should be one, must be fully OO and have
>> native Ada interface.
> 
> Which is unthinkable without Ada ABI. I'm missing Dylan's "sealed/
> unsealed".

Well, maybe. It is required if agents (mobile object) have to be supported
on the OS level.

>> An OO OS is unthinkable without MI, MD and safe
>> (non-cooperative) tasks and protected objects.
> 
> What PL family do you mean:
> Sather/Eiffel, C++, Dylan/CLOS?

Ada

> BTW, in '88 or so there existed an OO-extension for Ada. It was called
> InnovAda.

I never heard about it.

I am satisfied with Ada 95 OO model. It was consistent but incomplete. Now
it must be made finished. Major things to add are:

1. Classes for all types
2. MI
3. MD
4. Supertypes
5. Procedural types
6. Proper construction/destruction

For OS:

7. Non-cooperative multitasking

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

Re: Ada OS based on Minix3

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> 6. Proper construction/destruction

What do you see as the limitations/problems with Ada in this area?

- Bob

Re: Ada OS based on Minix3

[Dmitry A. Kazakov]

On Mon, 10 Nov 2008 10:31:27 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> 6. Proper construction/destruction
> 
> What do you see as the limitations/problems with Ada in this area?

1. User-defined initialization/finalization shall be definable for any
type. I do mean any.

2. Composition rules of initialization/finalization for derived types must
ensure execution of the user-defined initialization/finalization code for
the base type.

3. User-defined initialization/finalization shall be definable for
class-wide types. AKA dispatch from constructor/destructor. Actually, a
part of the pos. 1.

4. Task-as-a-component problem to be solved.

5. Getting a pool-specific pointer to the object upon
initialization/finalization, when the object is allocated in such a pool.
(Unchecked_Conversion is really nasty there)

6. LHS/RHS issue.

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

Re: Ada OS based on Minix3

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Mon, 10 Nov 2008 10:31:27 -0500, Robert A Duff wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> 6. Proper construction/destruction
>> 
>> What do you see as the limitations/problems with Ada in this area?
>
> 1. User-defined initialization/finalization shall be definable for any
> type. I do mean any.

Finalization: Agreed, but the compiler really needs to take care to
avoid distributed overhead.

Initialization: Use function calls.  They work for all types.
I think we've discussed this idea before, but I don't remember
any fundamental problems.  The Initialize procedure of controlled
types seems unnecessary to me (although something needs to be done
regarding abort deferral).

> 2. Composition rules of initialization/finalization for derived types must
> ensure execution of the user-defined initialization/finalization code for
> the base type.

Agreed (except I think you mean "parent type", not "base type").
This is a more general issue -- it would be useful to say
"must call parent op" for various things, including Finalize.

> 3. User-defined initialization/finalization shall be definable for
> class-wide types. AKA dispatch from constructor/destructor. Actually, a
> part of the pos. 1.

OK.  There are some interesting issues here -- the constructor (a
function, in my mind) might want to plug a pointer-to-classwide into
some global data structure, but I want to make sure the specific-typed
thing is fully initialized and ready to be dispatched to, before that
happens.

> 4. Task-as-a-component problem to be solved.

Which problem is that?

> 5. Getting a pool-specific pointer to the object upon
> initialization/finalization, when the object is allocated in such a pool.
> (Unchecked_Conversion is really nasty there)

I think you mean Unchecked_Access -- Unchecked_Conversion is not
necessary.

I don't see how this can make sense.  In Initialize or Finalize, you
don't know whether the object is in a pool, nor which pool.  So how can
you get a pool-specific pointer?

Also, given point 1 ("any type") the thing being init/finalized could be
a bitfield component of a packed record.  Pointers to bitfields could
cause distributed overhead, if you're not careful.

> 6. LHS/RHS issue.

What issue is that?

How about:

7. It would be nice if Finalize would be passed a parameter indicating
   the reason for finalization (normal exit, some exception occurrence,
   abort).  Perhaps also an ability to declare that finalization only
   applies to certain "reasons".

8. Interactions with user-defined storage pools.

9. Interactions with garbage collection.

10. Reify the finalization operation (that is, the operation on some
    type that calls Finalize on all the parts of it, including the
    whole).

- Bob

Re: Ada OS based on Minix3

[Dmitry A. Kazakov]

On Tue, 11 Nov 2008 17:09:54 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Mon, 10 Nov 2008 10:31:27 -0500, Robert A Duff wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>> 6. Proper construction/destruction
>>> 
>>> What do you see as the limitations/problems with Ada in this area?
>>
>> 1. User-defined initialization/finalization shall be definable for any
>> type. I do mean any.
> 
> Finalization: Agreed, but the compiler really needs to take care to
> avoid distributed overhead.

I don't see why it should be a distributed overhead. For example, access
types are already initialized by null. The overhead, if any, is here, but
it does not hurt.

> Initialization: Use function calls.  They work for all types.
> I think we've discussed this idea before, but I don't remember
> any fundamental problems.

The fundamental problem is that a constructor cannot be decomposed into
functions. In the function body you have to construct the object before you
return it. Who does it and what?

Under initialization I do not mean replacing a "default" value with
something else. I mean creation a new object (at some memory location)
initialized by a value. It had no other value before.

Doing this by a function is semantically wrong.

> The Initialize procedure of controlled
> types seems unnecessary to me (although something needs to be done
> regarding abort deferral).

Right, because Initialize receives an already constructed object. It is too
late to do many type-specific initializations, but too early to make the
class-wide ones.

>> 2. Composition rules of initialization/finalization for derived types must
>> ensure execution of the user-defined initialization/finalization code for
>> the base type.
> 
> Agreed (except I think you mean "parent type", not "base type").

Well, I am unsure if there must be such distinction in the first place.
But, OK, to begin with, let it be parent type.

> This is a more general issue -- it would be useful to say
> "must call parent op" for various things, including Finalize.

Yes, it would be great to have "extensible" primitive operations.

>> 3. User-defined initialization/finalization shall be definable for
>> class-wide types. AKA dispatch from constructor/destructor. Actually, a
>> part of the pos. 1.
> 
> OK.  There are some interesting issues here -- the constructor (a
> function, in my mind) might want to plug a pointer-to-classwide into
> some global data structure, but I want to make sure the specific-typed
> thing is fully initialized and ready to be dispatched to, before that
> happens.

Right.

>> 4. Task-as-a-component problem to be solved.
> 
> Which problem is that?

I mean the pattern:

   type Active is new Ada.Finalization.Limited_Controlled ...;
private
   task Agent (Object : not null access Active'Class) ...
   type Active is new Ada.Finalization.Limited_Controlled with record
      Agent : Task (Active'Access);
   end record;

It is broken, not even worth to try.

Even in rare cases when the component task does not refer to its container
type, the only way to make it working is to have a pointer to the task
instead.

In fact, any mix-in with an access to class-wide is extremely dangerous and
error prone, *because* it is very difficult to initialize and finalize such
things properly. But this is another story (about why we should have MI).

>> 5. Getting a pool-specific pointer to the object upon
>> initialization/finalization, when the object is allocated in such a pool.
>> (Unchecked_Conversion is really nasty there)
> 
> I think you mean Unchecked_Access -- Unchecked_Conversion is not
> necessary.
> 
> I don't see how this can make sense.  In Initialize or Finalize, you
> don't know whether the object is in a pool, nor which pool.  So how can
> you get a pool-specific pointer?

That is exactly the problem. Consider objects allocated on a user-defined
pool. The object are linked into some list. When a new object is created
the "constructor" places it into the list. When the object is destroyed,
the "destructor" removes it. For both, you need a self-pointer, but you
cannot get it from an "in out" parameter. If access types had
constructors/destructors, the programmer could place that stuff there,
rather that trying to do it in the object. It does not belong there.

> Also, given point 1 ("any type") the thing being init/finalized could be
> a bitfield component of a packed record.  Pointers to bitfields could
> cause distributed overhead, if you're not careful.

This is an issue how a constructor is chosen by the compiler. 

>> 6. LHS/RHS issue.
> 
> What issue is that?

I meant access to the left part of assignment. Provided that the assignment
is to be generated out of the constructor and destructor.

> How about:
> 
> 7. It would be nice if Finalize would be passed a parameter indicating
>    the reason for finalization (normal exit, some exception occurrence,
>    abort).  Perhaps also an ability to declare that finalization only
>    applies to certain "reasons".

Yes, I always wished to have this for DB transaction objects. When the
object is killed by an exception propagation it rolls the updates back.
Otherwise it commits.

> 8. Interactions with user-defined storage pools.
> 
> 9. Interactions with garbage collection.

I hope this can be solved on the basis of the constructor/destructor of the
corresponding access type.

Pool-specific named access types is one of the coolest things in Ada, IMO.

> 10. Reify the finalization operation (that is, the operation on some
>     type that calls Finalize on all the parts of it, including the
>     whole).

I.e. a destructor. But it is semantically broken to have such. It would
destroy an object leaving a dangling typed name of.

I think that the trick can be achieved with an access type to some fake
storage pool. The Unchecked_Deallocation is called on the pointer. That
does the finalization. Then the pool's Deallocate is called, which does
nothing.

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

Re: Ada OS based on Minix3

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:14ay3vz2ngj9s.1bmilwgckl3lc$.dlg@40tude.net...
...
>>> 5. Getting a pool-specific pointer to the object upon
>>> initialization/finalization, when the object is allocated in such a 
>>> pool.
>>> (Unchecked_Conversion is really nasty there)
>>
>> I think you mean Unchecked_Access -- Unchecked_Conversion is not
>> necessary.
>>
>> I don't see how this can make sense.  In Initialize or Finalize, you
>> don't know whether the object is in a pool, nor which pool.  So how can
>> you get a pool-specific pointer?
>
> That is exactly the problem. Consider objects allocated on a user-defined
> pool. The object are linked into some list. When a new object is created
> the "constructor" places it into the list. When the object is destroyed,
> the "destructor" removes it. For both, you need a self-pointer, but you
> cannot get it from an "in out" parameter.

Sorry, but this is completely wrong. This is *exactly* how Claw works, and 
it works fine with Ada 95. It is perfectly OK to get a pointer from a 
parameter of a tagged object. You do have to use 'Unchecked_Access, but that 
is no problem if you are using Finalize to clean up.

...
>> 10. Reify the finalization operation (that is, the operation on some
>>     type that calls Finalize on all the parts of it, including the
>>     whole).
>
> I.e. a destructor. But it is semantically broken to have such. It would
> destroy an object leaving a dangling typed name of.
>
> I think that the trick can be achieved with an access type to some fake
> storage pool. The Unchecked_Deallocation is called on the pointer. That
> does the finalization. Then the pool's Deallocate is called, which does
> nothing.

Yup. And you can do that now. So what's the big deal. At worst, it's not as 
convinient as it could be.

Most of the rest of the stuff that you and Bob have talked about is too 
incompatible to consider for Ada. A new Ada-like language could do these 
things, but there isn't much likelyhood of anyone using that.

                              Randy.

Re: Ada OS based on Minix3

[Dmitry A. Kazakov]

On Wed, 12 Nov 2008 18:58:33 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:14ay3vz2ngj9s.1bmilwgckl3lc$.dlg@40tude.net...
> ...
>>>> 5. Getting a pool-specific pointer to the object upon
>>>> initialization/finalization, when the object is allocated in such a 
>>>> pool.
>>>> (Unchecked_Conversion is really nasty there)
>>>
>>> I think you mean Unchecked_Access -- Unchecked_Conversion is not
>>> necessary.
>>>
>>> I don't see how this can make sense.  In Initialize or Finalize, you
>>> don't know whether the object is in a pool, nor which pool.  So how can
>>> you get a pool-specific pointer?
>>
>> That is exactly the problem. Consider objects allocated on a user-defined
>> pool. The object are linked into some list. When a new object is created
>> the "constructor" places it into the list. When the object is destroyed,
>> the "destructor" removes it. For both, you need a self-pointer, but you
>> cannot get it from an "in out" parameter.
> 
> Sorry, but this is completely wrong. This is *exactly* how Claw works, and 
> it works fine with Ada 95. It is perfectly OK to get a pointer from a 
> parameter of a tagged object. You do have to use 'Unchecked_Access, but that 
> is no problem if you are using Finalize to clean up.

No, that does not work with pool-specific types:

with Ada.Finalization;
package Test_Unchecked is
   type T is new Ada.Finalization.Limited_Controlled with private;
   overriding procedure Initialize (X : in out T);
   overriding procedure Finalize (X : in out T);
private
   type T_Ptr is access T'Class;
   type T is new Ada.Finalization.Limited_Controlled with null record;
   Global : T_Ptr;
end Test_Unchecked;

   procedure Initialize (X : in out T) is
   begin
      Add_To_List (Global, X'Unchecked_Access);
           -- Illegal, general access is required, but T_Ptr is expected
   end Initialize;

And it is error-prone. There should be nothing "unchecked" there.

If access type had its own initialization/finalization hooks at appropriate
places, we could move that stuff where it actually belongs to. After all,
you could have:

   type T_Pool_1_Ptr is access T'Class;
   for T_Pool_1_Ptr'Storage_Pool use Pool_1;
   Global_1 : T_Pool_1_Ptr;

   type T_Pool_2_Ptr is access T'Class;
   for T_Pool_2_Ptr'Storage_Pool use Pool_2;
   Global_2 : T_Pool_2_Ptr;

Objects allocated in Pool_1 are placed into Global_1 list. Objects
allocated in Pool_2 are in Global_2. Object initialization is just a wrong
place to manipulate these lists.

> Most of the rest of the stuff that you and Bob have talked about is too 
> incompatible to consider for Ada.

I strongly disagree. I see no incompatibilities. I think that proper
construction can be added without changing existing language behaviour.
Even Ada.Finalization can be left as-is.

Return statements and functions returning limited objects were IMO much
more obtrusive. "not null" stuff was plainly incompatible with Ada 95.
Nevertheless they were accepted.

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

Re: Ada OS based on Minix3

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:192kzxoa5qgu3.170vbwrazvhvp.dlg@40tude.net...
> On Wed, 12 Nov 2008 18:58:33 -0600, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:14ay3vz2ngj9s.1bmilwgckl3lc$.dlg@40tude.net...
>> ...
>>>>> 5. Getting a pool-specific pointer to the object upon
>>>>> initialization/finalization, when the object is allocated in such a
>>>>> pool.
>>>>> (Unchecked_Conversion is really nasty there)
>>>>
>>>> I think you mean Unchecked_Access -- Unchecked_Conversion is not
>>>> necessary.
>>>>
>>>> I don't see how this can make sense.  In Initialize or Finalize, you
>>>> don't know whether the object is in a pool, nor which pool.  So how can
>>>> you get a pool-specific pointer?
>>>
>>> That is exactly the problem. Consider objects allocated on a 
>>> user-defined
>>> pool. The object are linked into some list. When a new object is created
>>> the "constructor" places it into the list. When the object is destroyed,
>>> the "destructor" removes it. For both, you need a self-pointer, but you
>>> cannot get it from an "in out" parameter.
>>
>> Sorry, but this is completely wrong. This is *exactly* how Claw works, 
>> and
>> it works fine with Ada 95. It is perfectly OK to get a pointer from a
>> parameter of a tagged object. You do have to use 'Unchecked_Access, but 
>> that
>> is no problem if you are using Finalize to clean up.
>
> No, that does not work with pool-specific types:

As well it shouldn't. A decent abstraction should never, ever make 
assumptions about how the objects are created/allocated/managed. Doing so 
prevents the use of less-errorprone, more modern management schemes such as 
stack allocated objects and containers.

...
> And it is error-prone. There should be nothing "unchecked" there.

I don't disagree, but the use of access types should be a last resort. And 
they are error-prone by definition (the only way to make them not 
error-prone is to use local access types, but that assuredly finalizes 
things too soon, rather than too late). Trying to make them not error-prone 
is like putting wheels on a horse and calling an automobile.

> If access type had its own initialization/finalization hooks at 
> appropriate
> places, we could move that stuff where it actually belongs to.

Probably true, but completely irrelevant to my point.

...
>> Most of the rest of the stuff that you and Bob have talked about is too
>> incompatible to consider for Ada.
>
> I strongly disagree. I see no incompatibilities. I think that proper
> construction can be added without changing existing language behaviour.
> Even Ada.Finalization can be left as-is.

We have proper construction. You just don't like the way it is written. 
(Neither did I, initially. But it is the way it is done.)

The only problem with constructors is constructing into constrained objects. 
But that's easily solved: DON'T DO THAT!!! Don't export discriminants or 
bounds from your abstractions; declare them indefinite (with (<>)) and there 
are no issues. (Outside of the wording problems in the Standard -- it 
doesn't quite capture the intent -- but we're fixing them.)

> Return statements and functions returning limited objects were IMO much
> more obtrusive. "not null" stuff was plainly incompatible with Ada 95.
> Nevertheless they were accepted.

And we've taken a lot of flack for it. Going forward, we're probably going 
to be making many fewer incompatible changes.

And changing the place that allocated objects finalize (needed for your 
access type finalization proposal) or where tasks finalize (mentioned as one 
of your bullets) is just too likely to break existing code. I know Claw 
would break badly if the latter was changed. Moreover, I recall griping 
about the same problem you are complaining about vis-a-vis tasks when we 
were working on Claw -- but I looked at the alternatives, and they were all 
worse (much more likely to access stack objects that no longer exist, and 
thus requiring overhead-increasing dynamic checks). I don't think some of 
these problems are solveable within the constraints of the Ada language. 
(I'd like to be proved wrong, but I'd need to see a fully worked out 
proposal before I'd believe it.)

                                   Randy.

Re: Ada OS based on Minix3

[Dmitry A. Kazakov]

On Thu, 13 Nov 2008 17:25:53 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:192kzxoa5qgu3.170vbwrazvhvp.dlg@40tude.net...
>> On Wed, 12 Nov 2008 18:58:33 -0600, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:14ay3vz2ngj9s.1bmilwgckl3lc$.dlg@40tude.net...
>>> ...
>>>>>> 5. Getting a pool-specific pointer to the object upon
>>>>>> initialization/finalization, when the object is allocated in such a
>>>>>> pool.
>>>>>> (Unchecked_Conversion is really nasty there)
>>>>>
>>>>> I think you mean Unchecked_Access -- Unchecked_Conversion is not
>>>>> necessary.
>>>>>
>>>>> I don't see how this can make sense.  In Initialize or Finalize, you
>>>>> don't know whether the object is in a pool, nor which pool.  So how can
>>>>> you get a pool-specific pointer?
>>>>
>>>> That is exactly the problem. Consider objects allocated on a 
>>>> user-defined
>>>> pool. The object are linked into some list. When a new object is created
>>>> the "constructor" places it into the list. When the object is destroyed,
>>>> the "destructor" removes it. For both, you need a self-pointer, but you
>>>> cannot get it from an "in out" parameter.
>>>
>>> Sorry, but this is completely wrong. This is *exactly* how Claw works, 
>>> and
>>> it works fine with Ada 95. It is perfectly OK to get a pointer from a
>>> parameter of a tagged object. You do have to use 'Unchecked_Access, but 
>>> that
>>> is no problem if you are using Finalize to clean up.
>>
>> No, that does not work with pool-specific types:
> 
> As well it shouldn't. A decent abstraction should never, ever make 
> assumptions about how the objects are created/allocated/managed.

Right, and it does not. The object here is of a pool-specific access type
(access T'Class). We do not care how these objects are allocated. But we do
care how the target objects (T'Class) are allocated because that is the
core functionality of the access type.

>> And it is error-prone. There should be nothing "unchecked" there.
> 
> I don't disagree, but the use of access types should be a last resort.

Again true, but IF we offer access types, THEN they must be consistent with
the rest of the types system.

> And 
> they are error-prone by definition (the only way to make them not 
> error-prone is to use local access types, but that assuredly finalizes 
> things too soon, rather than too late). Trying to make them not error-prone 
> is like putting wheels on a horse and calling an automobile.

I don't think it is true. Access type expresses referential semantics.
There are use cases where this semantics can be implemented safely.

The problem with Ada's access types is that the programmer cannot influence
the built-in semantics of. Instead of that special cases are mounted on:
anonymous, pool-specific, null-constrained etc. Make it a proper ADT and
let the programmer to deal with that mess.
 
>> If access type had its own initialization/finalization hooks at 
>> appropriate places, we could move that stuff where it actually belongs to.
> 
> Probably true, but completely irrelevant to my point.

If your point is "let's get rid of access types, where possible,' then I
fully agree with. But we cannot remove them altogether. So, they should be
implemented at least reasonably.

>>> Most of the rest of the stuff that you and Bob have talked about is too
>>> incompatible to consider for Ada.
>>
>> I strongly disagree. I see no incompatibilities. I think that proper
>> construction can be added without changing existing language behaviour.
>> Even Ada.Finalization can be left as-is.
> 
> We have proper construction. You just don't like the way it is written. 
> (Neither did I, initially. But it is the way it is done.)

How so? There is no user-defined construction for most of the language
types. In two cases where that is provided (Ada.Finalization), it is made
error-prone.

> And changing the place that allocated objects finalize (needed for your 
> access type finalization proposal)

Why should it change? It is the access type object to be finalized, not the
target. The finalization can collect the target object if the access type
were intended to implement a GC.

> or where tasks finalize (mentioned as one 
> of your bullets) is just too likely to break existing code.

Again no. All places remain same. The difference is that user-defined hooks
are called at these places. It will be possible to engage a rendezvous with
a task component upon finalization, because there will be a hook called
prior destruction of the object's components. I don't see why this should
break anything.

> I know Claw 
> would break badly if the latter was changed. Moreover, I recall griping 
> about the same problem you are complaining about vis-a-vis tasks when we 
> were working on Claw -- but I looked at the alternatives, and they were all 
> worse (much more likely to access stack objects that no longer exist, and 
> thus requiring overhead-increasing dynamic checks). I don't think some of 
> these problems are solveable within the constraints of the Ada language. 
> (I'd like to be proved wrong, but I'd need to see a fully worked out 
> proposal before I'd believe it.)

I do believe that there is no problem with that. We would not change
anything in the existing constructors and their behavior. We would just add
appropriate calls from within.

BTW, I don't propose constructors or destructors (that would be
fundamentally inconsistent), I do user insertions into the existing
(magically generated) constructors or destructors. That just cannot break
anything.

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

Re: Ada OS based on Minix3

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Tue, 11 Nov 2008 17:09:54 -0500, Robert A Duff wrote:
>> Initialization: Use function calls.  They work for all types.
>> I think we've discussed this idea before, but I don't remember
>> any fundamental problems.
>
> The fundamental problem is that a constructor cannot be decomposed into
> functions. In the function body you have to construct the object before you
> return it. Who does it and what?

In Ada 2005, a constructor function creates the object via another
function call, or via an aggregate, or via an uninitialized
variable (to which it assigns components).

> Under initialization I do not mean replacing a "default" value with
> something else. I mean creation a new object (at some memory location)
> initialized by a value. It had no other value before.

That's exactly what a function call does:

    X : T := F(...);

F creates a new object.  In the limited case, that object _is_ X.
In the nonlimited case, it gets copied into X.  Either way,
X has been turned from "raw bits" into an object of type T --
as you say, "it had no other value before."

> Doing this by a function is semantically wrong.

I agree with a lot of the rest of what you wrote,
which I snipped.

But I'm interested in discussing this particular point.
It seems to me the whole point of functions is to create
new objects.  Why is this "semantically wrong"?

I understand that there are tricky issues when constructing an
object of a specific type and then returning it as a class-wide
thing, and possibly storing pointer-to-classwide into global
data structures.  But I don't get what's fundamentally wrong
with using functions as constructors.

- Bob

Re: Ada OS based on Minix3

[Dmitry A. Kazakov]

On Fri, 14 Nov 2008 18:11:34 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Tue, 11 Nov 2008 17:09:54 -0500, Robert A Duff wrote:
>>> Initialization: Use function calls.  They work for all types.
>>> I think we've discussed this idea before, but I don't remember
>>> any fundamental problems.
>>
>> The fundamental problem is that a constructor cannot be decomposed into
>> functions. In the function body you have to construct the object before you
>> return it. Who does it and what?
> 
> In Ada 2005, a constructor function creates the object via another
> function call, or via an aggregate, or via an uninitialized
> variable (to which it assigns components).

Here we are. At the end of this chain there is always some magical
construct which is not a function. It is the construct which yields the
object of the type. The object is *already* constructed at this point, per
magic, not per function which is not yet even returned.

>> Under initialization I do not mean replacing a "default" value with
>> something else. I mean creation a new object (at some memory location)
>> initialized by a value. It had no other value before.
> 
> That's exactly what a function call does:
> 
>     X : T := F(...);
> 
> F creates a new object.  In the limited case, that object _is_ X.
> In the nonlimited case, it gets copied into X.  Either way,
> X has been turned from "raw bits" into an object of type T --
> as you say, "it had no other value before."

The "value before" is one set by the magical construct used within F. The
construct itself ultimately can neither be a function nor a procedure. F is
a factory function, merely a wrapper around allocator and some true
constructor.

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

Programmer controlled object creation (was: Re: Ada OS based on Minix3)

[Georg Bauhaus]

Dmitry A. Kazakov wrote:
> On Fri, 14 Nov 2008 18:11:34 -0500, Robert A Duff wrote:
> 
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>
>>> On Tue, 11 Nov 2008 17:09:54 -0500, Robert A Duff wrote:
>>>> Initialization: Use function calls.  They work for all types.
>>>> I think we've discussed this idea before, but I don't remember
>>>> any fundamental problems.
>>> The fundamental problem is that a constructor cannot be decomposed into
>>> functions. In the function body you have to construct the object before you
>>> return it. Who does it and what?
>> In Ada 2005, a constructor function creates the object via another
>> function call, or via an aggregate, or via an uninitialized
>> variable (to which it assigns components).
> 
> Here we are. At the end of this chain there is always some magical
> construct which is not a function. It is the construct which yields the
> object of the type. The object is *already* constructed at this point, per
> magic, not per function which is not yet even returned.

So what would programmer controlled object creation
look like?  I'm assuming you want the compiler to check
that usual Ada semantics is still intact. That is, all decisions about
size, alignment, placement, etc.

There be partial construction, IIUC? That is, some components
may be constructed late: Another function gets the partially
constructed object?  That is,

    function Make_Pizza (Hunger: Size) return Pizza;
      pragma Convention (Constructor, Make_Pizza);

    procedure Add_Topping (Object: in out Pizza; ...);
       -- creates a Topping component and fills it
       pragma Convention (Constructor, Add_Topping);

    type Pizza is tagged
       record
          Dough: Positive range 200 .. 1_000;
          Topping: ...;
        end record;

    function Make_Pizza (Hunger: Size) return Pizza is
    begin
       return Result: Pizza do
          -- we would NOT have an Object yet

          Pizza'Constructor(Dough => Grams (Hunger));
          --  we may NOT have a Topping component yet

          Add_Topping(Result);
             -- pass partial object (or info about it?)

          -- now we have a Topping component
       end return;
    end Make_Pizza;

Re: Programmer controlled object creation

[Dmitry A. Kazakov]

On Sat, 15 Nov 2008 12:57:12 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
>> On Fri, 14 Nov 2008 18:11:34 -0500, Robert A Duff wrote:
>> 
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>
>>>> On Tue, 11 Nov 2008 17:09:54 -0500, Robert A Duff wrote:
>>>>> Initialization: Use function calls.  They work for all types.
>>>>> I think we've discussed this idea before, but I don't remember
>>>>> any fundamental problems.
>>>> The fundamental problem is that a constructor cannot be decomposed into
>>>> functions. In the function body you have to construct the object before you
>>>> return it. Who does it and what?
>>> In Ada 2005, a constructor function creates the object via another
>>> function call, or via an aggregate, or via an uninitialized
>>> variable (to which it assigns components).
>> 
>> Here we are. At the end of this chain there is always some magical
>> construct which is not a function. It is the construct which yields the
>> object of the type. The object is *already* constructed at this point, per
>> magic, not per function which is not yet even returned.
> 
> So what would programmer controlled object creation
> look like?  I'm assuming you want the compiler to check
> that usual Ada semantics is still intact. That is, all decisions about
> size, alignment, placement, etc.
> 
> There be partial construction, IIUC? That is, some components
> may be constructed late: Another function gets the partially
> constructed object?  That is,
> 
>     function Make_Pizza (Hunger: Size) return Pizza;
>       pragma Convention (Constructor, Make_Pizza);
>
>     procedure Add_Topping (Object: in out Pizza; ...);
>        -- creates a Topping component and fills it
>        pragma Convention (Constructor, Add_Topping);
> 
>     type Pizza is tagged
>        record
>           Dough: Positive range 200 .. 1_000;
>           Topping: ...;
>         end record;
> 
>     function Make_Pizza (Hunger: Size) return Pizza is
>     begin
>        return Result: Pizza do
>           -- we would NOT have an Object yet
> 
>           Pizza'Constructor(Dough => Grams (Hunger));
>           --  we may NOT have a Topping component yet
> 
>           Add_Topping(Result);
>              -- pass partial object (or info about it?)
> 
>           -- now we have a Topping component
>        end return;
>     end Make_Pizza;

Nothing like that. A proposal was posted long ago:

http://groups.google.de/group/comp.lang.ada/browse_frm/thread/72c34c66b38e0e05?ie=UTF-8&oe=utf-8

The proposed sugar for constraints evaluation and construction hooks was:

   function Pizza'Get_Constraints (...) return Pizza'Constraints;
   procedure Pizza'Initialize (X : in out Pizza; ...);

The proposal contained examples of how the components become their
constraints from the parameters of a factory function. Of course there was
no such thing like partially constructed components.

BTW, it is Ada 2005 new feature that allows something like partial
construction:

function Make return T is
begin
   return R : T do
      ...
      raise I_Do_Not_Like_It;
   end return;
exception
   when I_Do_Not_Like_It =>
      return R : T do
         ...
      end return;
end Make;

Here the result is constructed twice.

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

Re: Ada OS based on Minix3

[Georg Bauhaus]

Ivan Levashew schrieb:

> Two general problems of starting an enterprise Ada project are as
> follows:
> Lack of libraries
> Lack of developers
> 
> While you can do little about the second, you can at least do binding
> generators.

Bindings work in a practical sense but they can
only perpetuate the lack of integration at another
level, the level of objects.

I understand there are at least these approaches:
- CORBA and the like
- .NET style type libraries
- OO ABI integration

What these approaches have in common could be condensed into
some sort of pragma Abstract_Machine, in the sense of the B method.

Re: Ada OS based on Minix3

[Freejack]

Cedric.Lannock wrote:
> Hi all,
> 
> I came across Ada at the beginning of the year and read quite a few
> books about Ada. A few month later I joined a Linux workgroup within a
> local computer association. This way I learned about Ada and had a
> look into Tanenbaum's book on operating systems (http://www.amazon.com/
> Operating-Systems-Implementation-Prentice-Software/dp/0131429388/
> ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1226066518&sr=8-1) and Minix 3
> (http://www.minix3.org/).
> 
> I thought about an operating system written fully in Ada. When surfing
> the net I came across the various discussions about that subject.
> 
> What taking the Minix 3 system as basis for porting it to Ada? The
> Minix 3 is a modern micro kernel os and has about 4.000 Lines of code.
> It is full Posix compatible. Some guys have added real time
> functionality to it (see ACM.org for further reading). Thus it would a
> good place to start. As it has to few lines of code it should be
> possible to build a kernel in overseeable time.
> 
> Another thought to get this project taking some speed would be not to
> rewrite all the available C code but to develop a translator c2ada. It
> would us getting startet and the resulting code could be enhanced and
> improved.
> 
> Do you think this would make this project doable?
> 
> Regards
> 
> Cedric Lannock

A better approach, in my humble opinion, would be start with an existing
kernel and expand outward.
For the longest time I've been thinking about making a Ravenscar Linux
Kernel Runtime Module. From there it could be expanded to include a full
Ada Runtime Environment, add an ABI, it's own System Calls, etc...
gradually replacing the functionality of the existing kernel, while
adding it's own OO functionality.

With this approach, you get an active test platform, access to an
"interface" that most developers are already familiar with(i.e. Posix),
while having the ability to gradually add more extensive non-posix
features to the platform. I'm certain the additional OO features will
attract users of other High Level language tools(Java, Haskell, OCaml,
etc..), at the same time it wouldn't alienate users of the more common
"system level" language tools(C, Assembler, Fortran, etc...).
Gradually, as more OO and Functional "paradigm"(I hate that word)
features are added, developers will begin to test, work with, and use
those features in thier userspace apps.

It really only takes a few developers to get a Kernel Module started and
working. The OpenRavenscar project has already done alot of the work for us.

What do you guys think?

dimonax

Re: Ada OS based on Minix3

[Martin Krischik]

Cedric.Lannock schrieb:

> Do you think this would make this project doable?

I was following the discussion for quite a while now and where left with
and important questions which you should ask yourself:

Which hardware should your OS run on?

If you need to reboot your computer for every test run it will slow you
down.

The answer is also important if you want other to try out you work. BeOS
only became slightly successful after it was ported to standard PC
hardware. (Not that I like standard PC hardware all that much).

Now, if I wanted to create an OS I would not target real hardware at
all. At least not in the beginning. I would probably implement the OS
inside a VMware virtual machine.

VMware would mean that my OS could be tries out on a Windows / Linux /
Mac OS System with out and repartition pain. Actually one could a ready
made create VMWare payer image significantly reducing the try out or
join the project hurdle.

Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada OS based on Minix3

[Peter C. Chapin]

Martin Krischik wrote:

> Now, if I wanted to create an OS I would not target real hardware at
> all. At least not in the beginning. I would probably implement the OS
> inside a VMware virtual machine.

What about targeting a hypervisor like Xen? If I understand correctly
(and I may not) that would separate the OS somewhat from the real
hardware and may help its portability in the long run.

Peter

Re: Ada OS based on Minix3

[Georg Bauhaus]

Peter C. Chapin schrieb:
> Martin Krischik wrote:
> 
>> Now, if I wanted to create an OS I would not target real hardware at
>> all. At least not in the beginning. I would probably implement the OS
>> inside a VMware virtual machine.
> 
> What about targeting a hypervisor like Xen? If I understand correctly
> (and I may not) that would separate the OS somewhat from the real
> hardware and may help its portability in the long run.

How could separation from the hardware do better than a
Microkernel such as Minix 3?

Full virtualization also deprives you of access to
a larger set of hardware. Which, I'd speculate, is not
too helpful when targetting mostly embedded system?

Re: Ada OS based on Minix3

[Ludovic Brenta]

Georg Bauhaus wrote:
> Peter C. Chapin schrieb:
> > Martin Krischik wrote:
>
>>> Now, if I wanted to create an OS I would not target real hardware at
>>> all. At least not in the beginning. I would probably implement the OS
>>> inside a VMware virtual machine.
>
>> What about targeting a hypervisor like Xen? If I understand correctly
>> (and I may not) that would separate the OS somewhat from the real
>> hardware and may help its portability in the long run.
>
> How could separation from the hardware do better than a
> Microkernel such as Minix 3?
>
> Full virtualization also deprives you of access to
> a larger set of hardware. Which, I'd speculate, is not
> too helpful when targetting mostly embedded system?

Georg, how do you know the OP wants to target embedded systems?

I personally think targetting Xen is a nice long-term goal because it
is unrealistic to think people will run an Ada operating system on a
dedicated machine. However, requiring that developers use and develop
on Xen might hinder adoption. It is better to do the initial
development targetting qemu or equivalent because, as Georg mentioned,
it lowers the barrier for contributors. After the kernel boots and
gains critical mass (i.e. becomes usable), comes time to think about
Xen and real hardware. BTW, this is exactly what Lovelace does --
hint, hint :)

--
Ludovic Brenta.

Re: Ada OS based on Minix3

[Georg Bauhaus]

Ludovic Brenta schrieb:

> Georg, how do you know the OP wants to target embedded systems?

I don't know, it seems reasonable, though, to assume
embedded systems here because Minix 3 announcements
say it is being made suitable for small, embeddable systems:

 "MINIX 3  adds the new goal of being usable as a serious
  system on resource-limited and embedded computers and for
  applications requiring high reliability"  (minix3.org)

Thinking again, though, if I'd want to offload the
portability work to a non-Ada layer below an Ada
kernel, e.g. Xen etc. block drivers, the interesting
plan that Dmitry Kazakov has laid out might have a better
chance, as there is more time to concentrate on an OS
featuring a better API. (E.g. modules, not functions).

And, you're right, results might be usable earlier,
provided there is more hardware supporting Xen drivers
than original drivers.

(Incidentally, it is possible to run Minix 3 on VMWare
Workstation.  I needed to select to a version 5
virtual machine, though.)

Re: Ada OS based on Minix3

[Martin Krischik]

Hi Ludovic,

Ludovic Brenta schrieb:
> Georg Bauhaus wrote:
>> Peter C. Chapin schrieb:
>>> Martin Krischik wrote:
>>>> Now, if I wanted to create an OS I would not target real hardware at
>>>> all. At least not in the beginning. I would probably implement the OS
>>>> inside a VMware virtual machine.
>>> What about targeting a hypervisor like Xen? If I understand correctly
>>> (and I may not) that would separate the OS somewhat from the real
>>> hardware and may help its portability in the long run.
>> How could separation from the hardware do better than a
>> Microkernel such as Minix 3?
>>
>> Full virtualization also deprives you of access to
>> a larger set of hardware. Which, I'd speculate, is not
>> too helpful when targetting mostly embedded system?
> 
> Georg, how do you know the OP wants to target embedded systems?
> 
> I personally think targetting Xen is a nice long-term goal because it
> is unrealistic to think people will run an Ada operating system on a
> dedicated machine. However, requiring that developers use and develop
> on Xen might hinder adoption. It is better to do the initial
> development targetting qemu or equivalent because, as Georg mentioned,
> it lowers the barrier for contributors.

Actually that was me who suggested it. qemu sound good, supports the 3
important OS and ready made disk images for "quick install and try out".

Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada OS based on Minix3

[Martin Krischik]

Hi Georg,

Georg Bauhaus schrieb:
> Peter C. Chapin schrieb:
>> Martin Krischik wrote:
>>
>>> Now, if I wanted to create an OS I would not target real hardware at
>>> all. At least not in the beginning. I would probably implement the OS
>>> inside a VMware virtual machine.

>> What about targeting a hypervisor like Xen? If I understand correctly
>> (and I may not) that would separate the OS somewhat from the real
>> hardware and may help its portability in the long run.

> How could separation from the hardware do better than a
> Microkernel such as Minix 3?

Speaking of Microkernel: what ever happened to the ring concept? Why
this all (ring 0) and nothing (ring 3) everywhere? After all one of the
most stable OS's - ever - used 4 privilege modes:

http://en.wikipedia.org/wiki/VAX#Privilege_Modes privilege mode.

Interesting to see that the File System runs in it's own mode -
especially when one considers the recent FUSE development.

Using 4 privilege modes certainly would be something I would investigate
when trying out OS design.

> Full virtualization also deprives you of access to
> a larger set of hardware. Which, I'd speculate, is not
> too helpful when targeting mostly embedded system?

Actually I see the "larger set of hardware" as a disadvantage for a new
OS. For a small OS with a few or only one developers the is just not
enough horse power to produce tons and tons of different device driver.

With full virtualization you just have one set of hardware to produce
device driver for which leaves you with more time for the interesting
things like new revolutionary OS design.

Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada OS based on Minix3

[Martin Krischik]

Peter C. Chapin schrieb:
> Martin Krischik wrote:
> 
>> Now, if I wanted to create an OS I would not target real hardware at
>> all. At least not in the beginning. I would probably implement the OS
>> inside a VMware virtual machine.
> 
> What about targeting a hypervisor like Xen? If I understand correctly
> (and I may not) that would separate the OS somewhat from the real
> hardware and may help its portability in the long run.

I knew that this question would come ;-) - The answer is simple: Xen is
not available for Window and Mac OS X hosts - together they amount to
90% of all desktop OS.

While Ada programmer are not like the average user and are more likely
to use Linux shutting out Windows and Mac OS X would still shut out a
lot of potential users and beta testers.

And even on Linux it is not all that easy. I can install a VMware Player
in no time on Linux but never quite succeeded in getting Xen to work.
Even with SuSE Linux which comes with a Xen plug-in for Yast.

So in short: Xen is not all that portable and would defeat the "quit
install and try it out" objective.

Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada OS based on Minix3

[Thomas Locke]

Martin Krischik wrote:
> I knew that this question would come ;-) - The answer is simple: Xen is
> not available for Window and Mac OS X hosts - together they amount to
> 90% of all desktop OS.
> 
> While Ada programmer are not like the average user and are more likely
> to use Linux shutting out Windows and Mac OS X would still shut out a
> lot of potential users and beta testers.
> 
> And even on Linux it is not all that easy. I can install a VMware Player
> in no time on Linux but never quite succeeded in getting Xen to work.
> Even with SuSE Linux which comes with a Xen plug-in for Yast.

How about Virtualbox then:

http://www.virtualbox.org/wiki/Downloads

It's fairly light, supports a wide range of platforms, there's an OS 
edition, and it works extremely well.

I can highly recommend Virtualbox, and I've only been using it for a few 
months. I moved to Virtualbox from VMware. I find that Virtualbox is 
easier to get going (running Slackware 12.1), lighter on resources and 
faster. It's basically just a very nice piece of software.

Oh, and the docs are quite extensive, which is very nice.

:o)
/Thomas

Re: Ada OS based on Minix3

[Alex R. Mosteo]

Thomas Locke wrote:

> Martin Krischik wrote:
>> I knew that this question would come ;-) - The answer is simple: Xen is
>> not available for Window and Mac OS X hosts - together they amount to
>> 90% of all desktop OS.
>> 
>> While Ada programmer are not like the average user and are more likely
>> to use Linux shutting out Windows and Mac OS X would still shut out a
>> lot of potential users and beta testers.
>> 
>> And even on Linux it is not all that easy. I can install a VMware Player
>> in no time on Linux but never quite succeeded in getting Xen to work.
>> Even with SuSE Linux which comes with a Xen plug-in for Yast.
> 
> How about Virtualbox then:
> 
> http://www.virtualbox.org/wiki/Downloads
> 
> It's fairly light, supports a wide range of platforms, there's an OS
> edition, and it works extremely well.
> 
> I can highly recommend Virtualbox, and I've only been using it for a few
> months. I moved to Virtualbox from VMware. I find that Virtualbox is
> easier to get going (running Slackware 12.1), lighter on resources and
> faster. It's basically just a very nice piece of software.
> 
> Oh, and the docs are quite extensive, which is very nice.

Using VBox here too, is a great piece of software. And, if I'm not mistaken, the virtualization part is (or started being) basically qemu's, so the emulated hardware may still be the same, and you'd get two birds in a shot.