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,39579ad87542da0e X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.21.226 with SMTP id y2mr2941633wie.5.1369279533602; Wed, 22 May 2013 20:25:33 -0700 (PDT) Path: hv6ni10057wib.1!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!border2.nntp.ams2.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!news.panservice.it!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Seeking for papers about tagged types vs access to subprograms Date: Thu, 16 May 2013 14:20:37 +0200 Organization: cbb software GmbH Message-ID: <1cj8b5amtua30.1foe0rdpldt2.dlg@40tude.net> 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> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.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-05-16T14:20:37+02:00 List-Id: On Thu, 16 May 2013 07:31:58 -0400, Peter C. Chapin wrote: > On Thu, 16 May 2013, Dmitry A. Kazakov wrote: > >>> Weren't we talking about "value" as a programming language term? >> >> You consider value being a language term. I objected, pointing out that >> value is the meaning of some program state, the meaning which is always >> outside the language and from the problem space. The only case when a >> value can be an Ada term is when the program is an Ada compiler. >> >>> I understand that to mean "value" as something used by people when >>> talking about programming languages. >> >> Yes. > > You said earlier, "value is the meaning of some program state..." So > "value" is, indeed, a term used when discussing programming languages. > That was my original contention. Recall that we were talking about types > and values and their relationship. I again return to my original > statement: a type is two sets, a set of values and a set of operations. > Are you disagreeing with that? No. Why should I? >> So, >> >> X, Y : Driver; >> >> have same values? > > Yes, I would say so. Really? X is an *equivalent* of Y? >> You seem to confuse value for its representation. The value of a task >> type is not even computable, or the value of clock. The representation >> of a task value might be a combination of some code, TCB, the state of >> system queues etc. > > I actually don't think I'm all that confused. I borrow concepts that are > standard in functional languages where functions are, indeed, first class > values. There a function's value is its (source) code. Two different > instances of the same function represent the same value just as two > different instances of the integer literal "2" represent the same value. 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? Either the values are different or else you need to bring some other stuff beyond types, values and operations into the picture. >> And what significance has Ada.Numerics' >> >> 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? If you think that values should have "significance", then what is significance? Why enumeration value does not have it and Universal_Integer does? P.S. What you call "significance" is the value. What you call "value" is a representation. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de