Re: Run-time accessibility checks

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

On Mon, 15 Dec 2008 19:53:02 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1xgim3qybjw07$.16nw9986hywhh.dlg@40tude.net...
> ...
>> 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.
> 
> This isn't inheritance, as it requires adding a selector of some sort (you 
> called it an index, Ada calls it a cursor) to the operations. At best, it is 
> some sort of automatic synthesis of operations.

Yes.

> But that again begs the 
> question of how to describe what it does -- I don't see any reasonable way 
> to do that. (How can you dispatch to an operation that has a different 
> number of parameters???)

No, you are trying to automate it in the compiler. That is not needed. The
the compiler should do only two things:

1. Create interface of the container type. The compiler knows the interface
of the elements and the index type. It is trivial to produce the
corresponding abstract primitive operations: for each Op of the element
type it creates Op of container *without* implementation.

2. Replace any Op(C(I)) with Op(C,I)

That's all. The implementation of these operations is the programmer's
business. Dispatch is trivial, it is dispatching when C is class-wide.

We don't need yet another built-in container type. We need only an
interface of a container type. The implementation will be provided by the
programmer.

>>> 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're claiming that every type that has a component of a type with 
> user-defined assignment also must have a user-defined assignment?

No. I want to be able to define an assignment.

(I don't want to extend Ada, I want to reduce it. We have much to many
built-in stuff, which should rather be provided at the library level.)

>>> 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.
> 
> That seems much more limiting than the cursor idea.

The inverse. Cursor requires persistent identity. It is an extremely strong
requirement with a number of nasty consequences (immovable elements for
example).

> It doesn't make any 
> sense to talk about the "second" item of a (generic) container.

That was an example when the index is an order. It is a property of the
index. No problem to have indices without order (for associative
containers).

> Consider a map referenced by strings, for instance.

Yes. In this case the index type is String. Where is any problem?

(Actually String is ordered. You likely meant another property: If I1, I2
in C, then I1<I<I2 in C, but that is no matter.)

> Moreover, elements of many forms of 
> container don't have any order, so you can't do anything useful with the 
> index by itself -- but operations like iteration are still meaningful.

No, if index is unordered and not dense, then iteration is meaningless. It
is a broken abstraction then. If you want to iterate a container you have
to order its elements. That is equivalent to existence some ordered dense
index of. The index can be of the type System.Address, that is no matter.
But to be able to iterate is a contract on the container. It is IMO a very
bad idea to assume all containers to fulfill this contract.

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