Re: Ada OS based on Minix3

["Randy Brukardt" <randy@rrsoftware.com>]

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