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,39579ad87542da0e X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.68.108.165 with SMTP id hl5mr6629384pbb.4.1368709814382; Thu, 16 May 2013 06:10:14 -0700 (PDT) Path: bp1ni2451pbd.1!nntp.google.com!news.glorb.com!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Thu, 16 May 2013 08:10:13 -0500 Newsgroups: comp.lang.ada Date: Thu, 16 May 2013 09:10:11 -0400 From: "Peter C. Chapin" X-X-Sender: peter@whirlwind Subject: Re: Seeking for papers about tagged types vs access to subprograms In-Reply-To: <1cj8b5amtua30.1foe0rdpldt2.dlg@40tude.net> Message-ID: References: <12gn9wvv1gwfk.10ikfju4rzmnj.dlg@40tude.net> <1oy5rmprgawqs.1jz36okze0xju$.dlg@40tude.net> <1q2ql1e4rcgko.diszzq1mhaq8$.dlg@40tude.net> <518dedd4$0$6581$9b4e6d93@newsspool3.arcor-online.net> <1um7tijeo609b$.1gtdijp0acfmn$.dlg@40tude.net> <1nkyb845dehcu.1sd90udwsrpdu.dlg@40tude.net> <1mg9eepp12ood$.14lj7s8a7eygd$.dlg@40tude.net> <1cj8b5amtua30.1foe0rdpldt2.dlg@40tude.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-5DXReLKJRu7c/3b7i9BOYwZMWU5WTNM4XxTQwUQPfQlY/PUwNJ8jvMSbupWWsBUeUO4FA8XBubSyZXQ!C2r00FburfjOjaS7g/0ppvl+OvalSy0dOeetZAQzCSYWHL4PFLvxB9Nq0aWNamz7dMXMubnsFQ== X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 5678 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Date: 2013-05-16T09:10:11-04:00 List-Id: On Thu, 16 May 2013, Dmitry A. Kazakov wrote: >>> So, >>> >>> X, Y : Driver; >>> >>> have same values? >> >> Yes, I would say so. > > Really? X is an *equivalent* of Y? Sure. If it were allowed the expression 'X = Y' should return True. I realize that equivalence of functions is a difficult concept in general (I believe it's undecidable to determine if two functions f_1 and f_2 are equivalent even if you can see the source code of both) but here since the code for both X and Y is, in fact, the very same program text, it seems clear that they are equivalent. X and Y above of course may contain different state information as they run but that's all related to the operation of execution; it doesn't distinguish their "task values." These concepts are all quite straightforward, it seems to me, in the context of functional languages. Of course Ada isn't a functional language and it has side effects, etc, so things do get a bit messier. I still contend, however, that the basic ideas still... er... apply. > Because the literal 2 [of type Integer] denotes the same value in all > contexts. But X, Y : Driver clearly do not do that. If X and Y are not > equivalent how they could have the same value? I guess this is where we disagree. To me X and Y do denote the same value in all contexts; they are equivalent. > Either the values are different or else you need to bring some other > stuff beyond types, values and operations into the picture. Are you referring to the execution state here? To my mind that dynamic information is just part of the operation of execution. It's necessary to make that operation work but, yes, I agree that it is a separate matter from the types and values, etc. Modeling state in a clean way is slippery business. You might be able to bring it into the context of this discussion by treating the state of each task as a kind of mutable parameter to the task. As such there could be an implicit type for that parameter... some kind of record type, etc... but it does get messy. >>> e : constant := >>> 2.71828_18284_59045_23536_02874_71352_66249_77572_47093_69996; >> >> As I understand it, 'e' has type Universal_Float and the 2.718... is a >> value inhabiting that type. I guess I don't understand what point you are >> making here. > > The point is about the value of e. You said that when declared as I did, it > has no significance, just a random pattern of bits. Do I interpret you > correctly? Does this same logic apply to e of Ada.Numerics? If not where is > a difference? We're talking about two different 'e's here. In the first case 'e' was an enumeration literal. The type in that example was suggestively named Transcendental_Constants (or something like that... I forget exactly), but any connection between 'e' and the mathematical value of e was purely in the mind of the programmer. In Ada terms 'e' was a value of that type but nothing beyond that. That's what I meant by it not having any significance. In the second case 'e' is a named number bound to a value in the Universal_Float type that is clearly intended to be the mathematical e... at least to the closest degree permitted by the available values in that type (I guess in this case it's really limited by the amount of space the implementer wants to use when writing the declaration. Am I correct in saying that Universal_Float has infinite precision?) I suppose I don't understand the point you were trying to make originally with the enumeration type. There 'e' was a value of the specified type. Was that it? Peter