Re: Run-time accessibility checks

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

On Fri, 12 Dec 2008 18:49:39 -0600, Randy Brukardt wrote:

>>> "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote
> ...
>>> The result of dereferencing an access value is a *different* type, with 
>>> *different* operations. I don't *want* interchangability!!
>>
>>Then you have what you have - an inability to assign an element in the 
>>container, *because* it is of a different type. In my solution the 
>>container element does not magically change its type, just because you 
>>don't want to copy it. Why should it? The container knows how to access its 
>>elements.
> 
> It sounds to me like you want container of X to have the operations of X. 
> They're not the same thing! That way lies madness, especially in that the 
> implementation costs will be very high. If you want that kind of 
> abstraction, I think you have to go to a fully dynamic language (which Ada 
> is not and never will be).

Not necessary. What I want is to leave the decision to the programmer.

BTW, it is another case, you are considering now:

   Op (C (I))

You suggest that this should *always* mean:

1.  Op (Dereference (Get_Element_Access (C, I)))

But this is not the only possible way.

2. The variant you didn't like uses no access types

   Op (C, I)

but requires C to inherit a modified interface of its elements. I see
nothing wrong with that.

3. The variant which applies beloved access to the operation rather than to
the element:

   Do (C, I, Op'Access)

References to operations should be no problem, especially because it is a
inward closure, while in the variant 1 you have an outward reference
(=never works).

As for implementation costs of the variant 2, in any case they are not of
the compiler designer. As a programmer I am ready to pay them, because
there is a huge echelon of secondary problems you can't even approach with
1 or 3. They are simply unsolvable - a container of subtypes which is a
subtype of container of parent types etc. The variant 2 opens that door.
What is behind, I don't know.

> I'm not going to discuss this further, because you're clearly on the dark 
> side of this issue, and further discussion would be like trying to explain 
> to "anon" why he's wrong. ;-)

I am the only one who uses all Ada 2005? (:-))

> [I'm also not seeing your messages for some 
> reason, had to grab this one off of Google Groups.]

Is your mail reader in Ada? (:-))

>>>> You certainly can't have a procedure ":=" to do assignment in because of 
>>>> discrimant-dependent components.
> 
>>>> ":=" is a statement. What I would do is to define *two* primitive 
>>>> subprograms the compiler will use in order to compose *one* ":=". The 
>>>> first operation will determine the discriminants, the second will 
>>>> continue with those known.
> 
>>> That's not the problem; the problem is that components appear and 
>>> disappear, and there is no way to assign them.
> 
>>I don't see any problem. All discriminants are known in the *second* 
>>primitive operation. That allows you to write a case statement and assign 
>>existing components.
> 
> You're solving the wrong problem. (Yes, I did read the rest of the message 
> before replying here.) There is no problem with overriding the top-level 
> assignment operation, never has been. The problem is composition (which is 
> necessary so that the invariants of an abstraction are preserved). A 
> component does not know nor care about the discriminants of the object that 
> it is a component of. And it could not, in general, or again you have 
> descended into madness (no type can enumerate all of the places it could 
> possibility be used).

But discriminants leak anyway. You cannot have an unconstrained component
without passing its constraint in some form to the container. If that is a
broken abstraction, then it is already broken by someone else. The
container type knows its actual components and assigns them. What else
composition is needed?

> You've called that abstraction an index, but it is the exact same abstraction.

The difference can be illustrate on:

   A (I) = B (I)

The index value I applies to any container that uses it, independently on
the container content. You can have an index without any container:

   for I in 1..200 loop
       Put_Line ("Hallo!");  -- No any containers in sight
   end loop;

> And it would need the exact same rules 
> for updates and the like, giving the same effects that you don't like.

No, it is not an error to do anything with the container while thinking
about "the second element of." Cursor and index are fundamentally different
things. Indices do not persist, they do not require identity of the element
etc.

>> You have pointer model in mind. But there is no pointers in my world. 
>> There is a setter operation. The setter takes an index argument, it is not 
>> my business to look into the implementation of.
> 
> Well, *someone* has to worry about the implementation model, and that is 
> what I was talking about. It doesn't matter how wonderful the abstraction is 
> if no one can implement it efficiently. Requiring a map to use a map to 
> resolve its cursors is definitely insane.

How are you going to implement packed containers of bits stored in a
hardware register?

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