From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,7d83a6223f4f2443 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!oleane.net!oleane!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Run-time accessibility checks (was: Construction initialization problem) Date: Fri, 12 Dec 2008 18:49:39 -0600 Organization: Jacob Sparre Andersen Message-ID: References: NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1229129436 27431 69.95.181.76 (13 Dec 2008 00:50:36 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 13 Dec 2008 00:50:36 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5512 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Xref: g2news2.google.com comp.lang.ada:3953 Date: 2008-12-12T18:49:39-06:00 List-Id: >> "Dmitry A. Kazakov" 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.