Re: Ada OS based on Minix3

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"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