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.224.217.195 with SMTP id hn3mr25663481qab.5.1368703920319; Thu, 16 May 2013 04:32:00 -0700 (PDT) Path: y6ni49044qax.0!nntp.google.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 06:32:00 -0500 Newsgroups: comp.lang.ada Date: Thu, 16 May 2013 07:31:58 -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: <1mg9eepp12ood$.14lj7s8a7eygd$.dlg@40tude.net> Message-ID: References: <1bfhq7jo34xpi.p8n2vq6yjsea.dlg@40tude.net> <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> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-QEqK4RuBofwBc8y08gTaZ9Nc9a9Ww0PYNAAsG5RqV/6GEnqD8HUe3sVB+3slqQInNW6qXapBgiq71O4!Z1iiXHFwRxe39+jP7chAa1nCQIvSWXSkdCf9S47f0eGtHHUaIgjMCJg5o4yhs47Eq8wt4+ikbA== 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: 5722 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Date: 2013-05-16T07:31:58-04:00 List-Id: 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? I honestly can't tell. > So, > > X, Y : Driver; > > have same values? Yes, I would say so. > 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. The machine representation of a function---how it is converted to executable form---is at the compiler's discretion, of course. In some languages function types have only a single operation, that of "application" (calling). Some of the items you mentioned above exist to support the execution of that operation; they are not part of the value. Ada tasks are not quite like functions but conceptually there are similarities. One important limitation of Ada is that every task type is inhabited with only a single value. It isn't possible to create multiple task bodies behind a task type definition. In contrast consider: function F1(X : Integer) return String; function F2(X : Integer) return String; Here F1 and F2 have the same "function type." They are two different values that inhabit that type just as "2" and "3" are two different values inhabiting Integer. But if you say task type T is ... end T; You can only write one body to go with the type. Every instance of type T thus has the same value---the type has only one value. This limitation doesn't change the concepts, it just reflects a limitation of Ada. In the more general case there would be "task operators" that would allow you to compose tasks to make new tasks (higher order tasks?) and you would be able to store different tasks into the same variable of task type provided all the tasks had the same type (but possibly different bodies). Of course this language isn't Ada. That said, the Ada 2005 features of synchronized and protected interfaces are moving into this terrian. A full theoretical accounting of Ada task types would be a very interesting exercise (has it been done?). > 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. I apologize if I cut too much context. Peter