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: 103376,73cb216d191f0fef X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.66.173.10 with SMTP id bg10mr12644pac.27.1363420325344; Sat, 16 Mar 2013 00:52:05 -0700 (PDT) Path: jm3ni52688pbb.0!nntp.google.com!news.glorb.com!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Is this expected behavior or not Date: Sat, 16 Mar 2013 08:51:54 +0100 Organization: cbb software GmbH 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> <5140f1ad$0$6634$9b4e6d93@newsspool2.arcor-online.net> <7jct0noryc1v.1rnj5kkzx6m35.dlg@40tude.net> <5141c499$0$6642$9b4e6d93@newsspool2.arcor-online.net> <18r2kop6fyozu.tctrjnghfxqs.dlg@40tude.net> <1wv3p3nrtejfk$.bwebhg9agt0l.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: p+zKE0HPHYmgiZzsZLLeGQ.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2013-03-16T08:51:54+01:00 List-Id: On Fri, 15 Mar 2013 16:17:11 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:ewe0v3ck1xdo$.e8rtuof27ke6$.dlg@40tude.net... >> On Thu, 14 Mar 2013 17:12:28 -0500, Randy Brukardt wrote: >> >>> There are some differences in *dynamic* behavior, but that has nothing to do >>> with the available values and operations. (The text you quoted from the RM >>> about values "belonging" to a subtype is defining dynamic behavior.) I >>> recall some Dmitry guy telling us that dynamic behavior is different from >>> static behavior, and even claiming that dynamic behavior cannot constitute a >>> contract. So it if is not a *contract*, how come it matters for a *type* >>> (which is an integral part of describing a contract)? >> >> I don't understand the point you are making. You cannot derive contract >> from behavior, simply because it is converse: contract is imposed to >> restrain possible behaviors. >> >> You might claim that implied contracts of Integer and Positive are exactly >> same. I doubt that many would agree with that. > > I certainly wouldn't, because *I* consider the dynamic behavior to be part > of the contract. But, clearly, you don't (and you've indicated that above > again. So yes, given your world view, the contracts of Integer and Positive > are exactly the same. That's clear, because they're interchangable in terms > of legality and resolution (anything having to do with compile-time > checking). The quote above says that you disagree with yourself. :-) That would be a consequence of considering them same type. I already said, that this a path towards weak typing. But I don't see where I disagree with myself. Contract /= type. You can have same contract and different types. What about: type Same is new Integer; You also can have different contracts put on the same type in different contexts. You can have contracts on something that does not involve types at all. Anyway, I fail to see how contracts are relevant here. > "I doubt that many would agree with that." That's certainly true, but that's > because few would agree with you on the notion that the contract does not > include the dynamic behavior. In any case, either *you* have to agree with > this premise (and thus all of your arguments on type vs. subtypes are > nonsense), or you are no longer agreeing with your previous statements about > contracts (which I for one would welcome, but it's seems pretty unlikely of > a change). I don't see why. How *any* contract could make something like Positive a non-type? There is not many possibilities: A. Positive is not a type. This is what Georg says. I have no idea what this is supposed to mean. That 123 is not Positive, or that "+" is not applied to positives? He escapes into some kind of vague philosophy each time I ask. B. Positive is a type. The type is Integer. So Positive = Integer. This is evidently wrong because there exist programs which semantics sufficiently change when 'Integer' is replaced by 'Positive'. If the language treats them same, worse to the language. Luckily Ada checks if Positive is indeed positive (well, not always, but almost). C. not (A or B) = my point. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de