Re: Ada OS based on Minix3

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

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