Re: Ada OS based on Minix3

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

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