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: a07f3367d7,5d4ade2fd8fd67c6 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder.news-service.com!feeder.erje.net!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Legit Warnings or not Date: Wed, 27 Jul 2011 19:37:55 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <531193e0-3305-4292-9ed8-0176226c1d00@x12g2000yql.googlegroups.com> <1rx6dwrxmc81p.eazb4fjqztox$.dlg@40tude.net> <1hi6gva8jhf7o.tq1yp29jn3qu.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1311813478 27985 69.95.181.76 (28 Jul 2011 00:37:58 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 28 Jul 2011 00:37:58 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Xref: g2news2.google.com comp.lang.ada:21361 Date: 2011-07-27T19:37:55-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1hi6gva8jhf7o.tq1yp29jn3qu.dlg@40tude.net... > On Tue, 26 Jul 2011 16:25:03 -0500, Randy Brukardt wrote: ... >> Why? Only the semantics of the objects should matter to the programmer; >> the >> rest of it should be left to the implementers. > > Yes, but 'Size, 'Address, 'Access, ":=" (deep vs. shallow), "=" (identity > vs. equality) are parts of the semantics, which aren't invariant to the > implementation. 'Address is obsolete junk that should never be used in new code (with the possible exception of static address clauses). For both 'Size and 'Address, they are meaningless in general unless the type is elementary or has a representation clause requiring a continuous representation. All of the other things are high-level concepts which work the same whether or not the objects are contiguous. ":=" and "=" are defined in terms of the subcomponents, 'Access provides an access to the object - the compiler has to chose the same representation for all such (aliased) objects, but there is no need for it to be contiguous. >> Besides that, it is impossible to implement Ada with solely contiguous >> objects -- the ability to pass slices means that array descriptors and >> the >> actual data have to be handled separately. > > To the programmer constraints are not a part of the object. E.g. it is OK > to have discriminants and bounds allocated elsewhere or not allocated at > all. Maybe that's the way you think of these, but I'm sure it's not universal. Discriminants, in particular, are defined by the language to be part of the object. And in any case, you are saying that discontiguous representations are fine so long as you think they are good idea. When did you get elected to be in charge of programmers? :-) >>> Expectations in an implementation of >>> Ada.Finalization.Adjust? >> >> The semantics of the language doesn't care if objects are contiguous or >> not. >> This is all invisible to the programmer if done right. > > This presumes a definition of the semantics of "bitwise copy". What is to > be copied before Adjust called? (The idea behind Adjust is broken anyway) The phrase "bit-wise copy" does not appear in the Standard, and plays no role in the formal definition of assignment and Adjust. ("bitwise" as you spelled it doesn't appear in the Standard or AARM at all.) I assume you got that from some informal description of how assignment works, but that's irrelevant in terms of a description of the language. Assignment of composite types is defined in terms of assigning all of the (elementary) subcomponents of the type (and then calling Adjust as needed). That does not require contiguous objects. >>>> There also are rules supporting allocation/deallocation of objects that >>>> have >>>> multiple parts. So far as I know, those are the only rules needed to do >>>> so. >>> >>> E.g. in a user-defined specific pool? >> >> Correct; the language allows multiple calls to Allocate for a single use >> of >> "new". > > Does it require this? How to enforce all parts to land into a pool? It can > be crucial for certain implementations. Require what? All of the parts of an designated object have to come from the same pool (I don't know how else it could work), the pool associated with the access type that the allocation is for -- that's the language requirement for "new". But there is no requirement that it be exactly one part. >>> As a customer I see that the language separates definite and indefinite >>> types. If this distinction is necessary, then the same logic applies to >>> the >>> implementation. I prefer transparent and simple implementations in order >>> to >>> know what to expect. In cases where I need referential semantics I >>> prefer >>> to implement it by myself, rather than to rely on the compiler. >> >> I don't think the distinction between definite and indefinite types IS >> necessary; it just one of many expediencies in the Ada language designed >> to >> ease implementation. They don't always help, and there is little value to >> forcing the same mistake on users. > > This is the core issue. I think it is important to have this distinction > as > well as contiguous objects in order to be able to use the language for > low-level programming. I want Ada to remain a universal programming > language. If you want contiguous objects to do low-level programming, I think it is reasonable to require you to declare that fact to the compiler. And a compiler that never supported such objects would clearly be a problem. But to require implementations to *never* use multiple parts for an object because someone, somewhere, might use some types for low-level programming is silly. After all, you can't use an Ada.Container type for low-level programming. Does that mean that Ada should not have container types? > I also think that a fully by-reference Java-like type system would be > necessarily inconsistent and incomplete. I don't want or advocate requiring much of anything to be by-reference. But I think that Ada compilers should be able to do the easy things (like T'Class and discriminant-dependent arrays) for clients without burdening them with the details. > I prefer a simpler language with means to hide references behind primitive > operations accessing fake components, fake array element etc. Moving the > mess to the library level. E.g. it should be OK to declare > > type A is array (...) of S'Class; > > but not as an implementation, because there could be many of them. Instead > of the compiler vendor choosing one for me, I prefer to make my own choice > out of several library implementations, or be able to implement it myself. Experience with containers shows that no one would use such things unless they were part of the predefined libraries. (Hardly any containers got any traction at all until Ada 2005 came along, even though they were plenty easy to define in any version of Ada.) So hardly anyone would use such abstractions. Moreover, you cannot create a *better* implementation than the one built-into the compiler (which doesn't have to have overhead to enforce Ada's rules as any abstracted version would). You might be able to generate one that works as well, but it would take heroic efforts in code generation to do so. (Keep in mind that hardly any compilers optimize finalization, even though it is possible and reasonably practical, mainly because of the difficulty of allowing arbitrary user code in such optimizations. The same would be true for your sorts of abstractions.) In any case, what I want is more power and more flexibility from Ada compilers (to do both contiguous and non-contiguous objects) to let the compiler do more hard work, rather than the programmer. You seem to want the programmer to work harder (and apparently never want anyone to use dynamic array objects in Ada, since those have the sort of implicit-reference semantics that you claim to hate). And it seems that further discussion is a waste of time, since there is no reason for either of us to change our opinions on this basic topic. Randy.