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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,65b902127ca8a604 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!news3.google.com!feeder.news-service.com!newsfeed.freenet.de!newsfeed00.sul.t-online.de!t-online.de!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Issue with GNAT GPL 2009 and GtkAda Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <4A414EBB.8060204@free.fr> <1avd65rn49abv$.krcxo2gdzb16$.dlg@40tude.net> <10ym4hltpwd4n$.1hcayfi4xidg3.dlg@40tude.net> <4a44842e$0$31872$9b4e6d93@newsspool3.arcor-online.net> <1hi0km5xe1802.17l3qjn1g9525$.dlg@40tude.net> Date: Tue, 30 Jun 2009 10:31:29 +0200 Message-ID: <1rq9846uwv807.qsr8exwb1sf9.dlg@40tude.net> NNTP-Posting-Date: 30 Jun 2009 10:28:16 CEST NNTP-Posting-Host: 945351b5.newsspool3.arcor-online.net X-Trace: DXC=j:mm<3>bS85gP]QSEBQ^d4McF=Q^Z^V384Fo<]lROoR1^YC2XCjHcb91obUf_i?@_7DNcfSJ;bb[5FCTGGVUmh?4LK[5LiR>kg2`1V[jFDAP14 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:6747 Date: 2009-06-30T10:28:16+02:00 List-Id: On Mon, 29 Jun 2009 16:59:40 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:u7txi934iaog$.gw40yhq8811x.dlg@40tude.net... >> On Fri, 26 Jun 2009 16:38:45 -0500, Randy Brukardt wrote: > ... >>> As far as the use of class-wide components, I think that would be easily >>> fixed by just allowing them. >> >> That would make objects non-contiguous. It is not obvious to me how that >> will work with streams and pools. I prefer a more transparent model when >> all components of a constrained object are constrained. > > Well, Ada has always allowed non-continguous objects. There is no problem > with streams: the stream attributes take care of any non-contiguous parts. > As for pools, multiple calls to Allocate are allowed; again there is no > requirement that the objects are contiguous. (That's been confirmed by > AI05-0107-1, but it has always been true for Ada 95; there are plenty of > AARM notes making that clear). OK, but I still feel bad about it. (:-)) >>> That would reduce the need to use access types some more. (But it can never >>> be completely eliminated; sometimes you really do need reference semantics, >>> especially for returns.) >> >> No, this is the mental trap. If something requires by-reference semantics >> that is not a return. Considering containers: >> >> A (I) := X; >> >> It is a semantic mistake to treat A (I) as a function "returning" >> something. This can only lead to introducing more and more strange >> constructs like limited aggregates, return statements and other mess. >> >> A (I) := X; >> >> must be treated as a syntax sugar for a procedure call >> >> Put (A, I, X); > > That works for full object assignment, but not in any sane way for in-place > component updating. And full object assignment really doesn't need any > special syntax (Replace_Element works just fine); the problem is when you > need to update a single element of a container which is itself an element. Ah, that is an interesting issue. Let us compare it on the example of multi-dimensional arrays. Should A(I,J) should better be A(I)(J)? I do not think that LHS indexing is "composable" in "C-way" without further assumptions. It should not be taken for granted. In cases of genuine reference semantics I would prefer a container of controlled access types to T rather than a container of aliased T returned by reference. I want it explicit like it is now: type Container is array (...) of access T; What is missing is finalization of access T by Unchecked_Deallocation and assignment T to access T by new T'(...). BTW, the public view of such container could be array of T. For example: type Container is array (...) of T is private; -- Not Ada! private type Container is array (...) of access T; -- implementation per controlled references > It doesn't make sense to try to think of these sorts of operations as a > single procedure. Why not? In general case of container composition, I would indeed provide the syntax: A (I, J, ...) := X; implemented by a primitive operation Put (A, I, J, ..., X); With introducing index types (tuples) it does not depend on dimension: Put (A, (I, J, ...), X); -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de