Re: Run-time accessibility checks (was: Construction initialization problem)

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

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

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'm also not seeing your messages for some 
reason, had to grab this one off of Google Groups.]

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

...

...
>> Not sure what you dislike about them; they've have the same semantics if 
>> not the same name. (I was talking about a record selector interface, 
>> which makes more sense for getting individual elements.)
>
> Referential semantics is what I dislike in cursors. Cursor is a dressed 
> pointer. It is very difficult to use it in concurrent/volatile 
> environment. It is inherently unsafe, what happens with it upon container 
> update? Where is that described? How to prevent update when a cursor is 
> still there. And so on, and so forth. Cursor is a bad, crippled thing.

The semantics of cursors are described in great detail in the language 
description. The short of it is that updating the container is certain ways 
while the cursor is outstanding is a bounded error. Either the cursor still 
points to the element, or Program_Error is raised. (Ignore Vector cursors 
for the moment, they're something else altogether.) Erroneousness is only 
allowed when the container itself is destroyed (such as with 
Unchecked_Deallocation).

As far as a concurrent environment goes, containers in general don't work 
well in such environments. You can define some special cases that make 
sense, but in general you have to have a protected environment that wraps 
the container. Cursors might make that worse, but surely are not the whole 
problem -- for instance, it is pretty much impossible to create a safe 
iterator for a general container in a concurrent environment. You have to 
lock the entire object for the entire time the iterator is active, and that 
pretty much kills concurrency.

And in any case, as one who is telling me that I'm thinking too low-level, 
it obvious that you are not looking at the abstraction of the cursor. All of 
cursor is logically is a means to find (reference - for the lack of a better 
word) an element in a container. You've called that abstraction an index, 
but it is the exact same abstraction. And it would need the exact same rules 
for updates and the like, giving the same effects that you don't like.

...
>> That would require a map to translate said index into some sort of access 
>> to the actual element. But that would be silly, especially for map 
>> containers (you'd have to go through two maps to find anything, and for 
>> what??)

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

>> But the real problem in all of these things you've suggested is that they 
>> are all technically by-copy for reading. If that is all you want, the 
>> existing Ada containers do that just fine. The problem is that if the 
>> elements are large, copying them may be very expensive, so a by-reference 
>> access method is reading. That's the core of the problem I'm trying to 
>> address (because I think there is a chance that people will view it as 
>> significant enough to deal with). Functions returning values of a type 
>> *do not* provide any solution to that (and cannot).

>This makes no sense to me. Reading is not an operation. If a primitive 
>operation of Element_Type has to be called on an element of Container_Type 
>specified by Index_Type, that is not "reading." If you mean "functional" 
>appearance of "getter," them firstly, it is not obvious why the getter is 
>to be used to achieve the goal, and secondly return by reference is marked 
>as "solved" in Ada 2005. Those Pickwickian functions were praised for that, 
>or? (:-))

As I said previously, container of X is not an X, and trying to make the two 
equivalent is the height of insanity.

And return-by-reference was removed from Ada 2005, not "solved". It didn't 
work in Ada 95, and it doesn't work in Ada 2005. No problem there. ;-)

                                               Randy.