Re: A hole in Ada type safety

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

On Sun, 08 May 2011 12:30:04 +0200, Florian Weimer wrote:

> * Dmitry A. Kazakov:
> 
>> Then a built-in access-to-component type might be a better solution. It
>> would eliminate a need for components to be aliased. Since the offset is
>> statically known (or a function that calculates it is), it need not to be
>> kept anywhere.
> 
> You'd still have the safety hazard with the reference to the outer
> record.  There are is some impact on encapsulation which has to be
> considered.  And it's not going to help with the original problem (a
> safer replacement for discriminants with defaults).

I don't think there is a solution for that. Variant components have no
static scope, so any reference can only be a weak one with dynamic checks.
I don't think that dynamic checks is a good idea. On the contrary, dynamic
accessibility checks is the most damaging feature Ada ever had.

>> OK, but you need to create the first reference somehow.
> 
> Uhm, I had imagined you'd use an allocator for that.  The whole thing
> is meant to be a bit similar to access values.

It would not work with stack-allocated objects.

Anyway, if you do it upon allocation, then in effect the reference count is
always there, "put" into the object either explicitly (via MI) or
implicitly (via the storage pool).

>>>> IMO weak references are quite useless if do not support notifications (when
>>>> the last strong reference is removed). I.e. you need a list of weak
>>>> reference holders.
>>> 
>>> I think they are supposed to be used for parent pointers in trees, for
>>> instance, to avoid the cycle issue.  Not so much for finalization.
>>
>> I rather use: parent-->child is a plain pointer, child-->parent is a
>> strong reference.
> 
> Dereferencing a weak pointer incurs a run-time check and operations on
> the counters (if reference counting is used), and the parent pointer
> is only needed for some traversal operations, so weak pointers upwards
> seem the way to go.

I considered that schema, but then dropped it. It was much simpler to have
children to hold their parents. Parent need not to have a reference to its
children because in the scenarios I considered, parent always controls its
children explicitly, e.g. when the tree is manipulated.

>> The most interesting cases for weak references are in the first line
>> finalization notification. E.g. cached objects.
> 
> You would get that with controlled types.

References must be "controlled" anyway, in the sense that reference
finalization is not null.

> I don't think weak references work for caches if you have reference
> counts and precise finalization because the last reference to the
> cached object goes away too soon.

Before the target object finalization occurs, all weak references get
notified and then invalidated when the strong count reaches zero. I don't
think that weak references asynchronously going invalid is a good idea.
Especially in tasking environment, where you cannot safely dereference weak
references, you have to temporarily promote them to strong references.

>> I think that the issue is too varying and complex to have it
>> built-in. I would prefer if Ada provided mechanisms for
>> implementation of such stuff at the library level. E.g. user-defined
>> access types with primitive referencing, dereferencing, finalization
>> operations. Classes of access types etc.
> 
> A pure library implementation would make certain optimizations
> difficult or impossible: for example, link-time replacement of
> tasking-safe counter implementations when there is no tasking, or
> avoidance of repeated counter operations on the same object.

Yes, but I would buy that. Hardware is cheaper than the software. When will
first implementations of such optimizations appear? How soon will they
become bug-free? How many generations of hardware will change in that
period of time?

> It also
> requires a lot of mechanics, adding more complexity to the language
> than a built-in facility.

No, it should simplify the language because this mechanics looks quite
universal to me. In particular it could make "access", "controlled" and
"tagged" types library level implementations.

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