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,73cb216d191f0fef X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.77.230 with SMTP id v6mr19957wiw.0.1363918501795; Thu, 21 Mar 2013 19:15:01 -0700 (PDT) MIME-Version: 1.0 Path: p18ni6019wiv.0!nntp.google.com!feeder1.cambriumusenet.nl!82.197.223.108.MISMATCH!feeder2.cambriumusenet.nl!feeder3.cambriumusenet.nl!feed.tweaknews.nl!216.196.110.142.MISMATCH!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!newsreader4.netcologne.de!news.netcologne.de!newsfeed.fsmpi.rwth-aachen.de!newsfeed.x-privat.org!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Is this expected behavior or not Date: Mon, 18 Mar 2013 17:52:03 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <8klywqh2pf$.1f949flc1xeia.dlg@40tude.net> <513f6e2f$0$6572$9b4e6d93@newsspool3.arcor-online.net> <513faaf7$0$6626$9b4e6d93@newsspool2.arcor-online.net> <51408e81$0$6577$9b4e6d93@newsspool3.arcor-online.net> <1xqmd3386hvns.1og1uql2cgnuf$.dlg@40tude.net> <5140b812$0$6575$9b4e6d93@newsspool3.arcor-online.net> <13y3efy877tjl$.5yuu230sknnq$.dlg@40tude.net> <1xsmzl7alqflb$.oz1qkrleisa7$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1363647125 7502 69.95.181.76 (18 Mar 2013 22:52:05 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 18 Mar 2013 22:52:05 +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.6157 Date: 2013-03-18T17:52:03-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:a9ivriefwvbm.1mwi80nz4jz6h$.dlg@40tude.net... > On Fri, 15 Mar 2013 16:43:47 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" wrote in message >> news:1xsmzl7alqflb$.oz1qkrleisa7$.dlg@40tude.net... >>> On Thu, 14 Mar 2013 16:51:11 -0500, Randy Brukardt wrote: >>> >>>> "Dmitry A. Kazakov" wrote in message >>>> news:13y3efy877tjl$.5yuu230sknnq$.dlg@40tude.net... ... >>>>> How do you describe tagged types in Ada 83 terms? >>>> >>>> Why would I want to? >>> >>> You insisted on that claiming that Ada can be only discussed in >>> Ada-terms. >> >> You didn't answer the question. Why would you want to describe something >> from a recent version of the language in terms of an obsolete one? > > To illustrate the point that one cannot extend/modify the language > discussing it in its terms, like baron Munchausen pulling yourself out of > a > swamp by your hair. We're not talking about extending or modifying the language, so that would not be relevant. > How would you tell yourself from year 1992 about Ada 95? The other you > would not listen to you. Well, in 1992, we were already working on implementation Ada 9x (which became Ada 95), as we were part of one of the user/implementer teams. So it wouldn't be hard at all to do. :-) And Ada 9x was described in terms of extending existing Ada concepts, so it wasn't that hard to understand at all. ... >>> Ada's subtype as defined by RM is a fact to explain (and to predict >>> consequences of the choices made). The theory does it quite well. The >>> rant >>> about how Ada's RM names its subtypes is absolutely irrelevant. >> >> But no one cares, because such matching has no relevance to anything: >> it's >> not going to change the design of Ada (compatibility concerns would >> prevent >> that in any case) > > There is no compatibility concerns. Robert said in this thread that > Prime'Range, Prime'First, Prime'Last are all illegal. So it is already > incompatible, if under compatibility you understand that a subtype must > inherit everything. Huh? In this content, "Compatibility" means new versions of Ada should not break existing Ada code. For the definition of 'Succ, for example, we cannot change it without potentially breaking existing code, so it is unlikely that we would make such a change. >> and nothing about it would help you be a better Ada >> programmer (especially as the terminology clash makes it close to >> impossible >> to think about one and make sense of the other). > > On the contrary, understanding that a subtype is a type with values and > operation helps a lot. Especially when it comes to aberrations like with > Prime'Succ. It is an operation of Prime and the programmer should know > that > in Ada he has no influence on its implementation which is always inherited > from the base type. If that does not correspond his intent he must change > the design and use other means, e.g. tagged types or unrelated types > (derive Prime privately). You seem to get the right conclusion from the wrong premise. If you understand that Positive is not a type, but rather *has* a type, and operations are chosen based on the type that Positive has (not by the subtype), then the behavior of 'Succ makes perfect sense, because its the same behavior that you get for "+" and "*" and all of the other predefined operations. Prime'Succ is thus an operation of Integer'Base (as subtypes like Prime don't have operations), and clearly how it behaves is based on that. And yes, if you want some other behavior, then you have to write it yourself -- nothing new about that. Randy.