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.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,447bd1cf7a88c198 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-15 13:22:07 PST Path: supernews.google.com!sn-xit-03!supernews.com!logbridge.uoregon.edu!newsfeed.berkeley.edu!ucberkeley!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: mark_lundquist@my-deja.com Newsgroups: comp.lang.ada Subject: Re: Subprogram types vs. "limited access" (was Re: Do we need "Mission-Critical" software? Was: What to Do? Date: Mon, 15 Jan 2001 21:06:02 GMT Organization: Deja.com Message-ID: <93vonj$3td$1@nnrp1.deja.com> References: <3A4F5A4A.9ABA2C4F@chicagonet.net> <3A4F759E.A7D63F3F@netwood.net> <3A50ABDF.3A8F6C0D@acm.org> <92qdnn$jfg$1@news.huji.ac.il> <3A50C371.8B7B871@home.com> <3A51EC04.91353CE7@uol.com.br> <3A529C97.2CA4777F@home.com> <3A53CB9E.EA7CF86C@uol.com.br> <3A5466DE.811D43A5@acm.org> <932aol$ikc$1@nnrp1.deja.com> <932mi6$r2k$1@trog.dera.gov.uk> <9343b1$3g5$1@nnrp1.deja.com> <934iuf$eqv$1@nnrp1.deja.com> <937kc7$ssq$1@nnrp1.deja.com> <93c0e9$4u6$1@nnrp1.deja.com> <93e33l$tfu$1@nnrp1.deja.com> <93ekmo$a14$1@nnrp1.deja.com> <93f73f$mt1$1@nnrp1.deja.com> <93fnao$49u$1@nnrp1.deja.com> <93l6ut$pvf$1@nnrp1.deja.com> <93mqhh$4gl$1@nnrp1.deja.com> <93npfn$13d$1@nnrp1.deja.com> <93q393$opo$1@nnrp1.deja.com> NNTP-Posting-Host: 130.213.200.127 X-Article-Creation-Date: Mon Jan 15 21:06:02 2001 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) X-Http-Proxy: 1.1 x56.deja.com:80 (Squid/1.1.22) for client 130.213.200.127 X-MyDeja-Info: XMYDJUIDmark_lundquist Xref: supernews.google.com comp.lang.ada:4027 Date: 2001-01-15T21:06:02+00:00 List-Id: In article <93q393$opo$1@nnrp1.deja.com>, dmitry6243@my-deja.com wrote: > In article <93npfn$13d$1@nnrp1.deja.com>, > mark_lundquist@my-deja.com wrote: > > In article <93mqhh$4gl$1@nnrp1.deja.com>, > > dmitry6243@my-deja.com wrote: > > > In article <93l6ut$pvf$1@nnrp1.deja.com>, > > > mark_lundquist@my-deja.com wrote: > > > > > BTW (if Robert does not hear us (:-)) I think that Ada > > > shuld have true subroutine types (not only pointers). The values > > > are passed by reference (always IN), > > > so in may cases the clusy trick > > > with generics will be not required. > > > > The downward closure thing again, huh? > > > > You have to define this idea of a procedure type to be limited (like a > > task) in order to really solve the problem, right? Note that that > > makes anything but an IN parameter illegal, so you also solve that > > problem without having to create essentially a new kind of parameter > > (as access parameters were). > > > > The first problem with subprogram parameters is a syntactic one -- > > what syntax do you use to establish its profile? Subprogram types as > > you suggest are one way to solve that problem, and they seem > > consistent with the "Ada way" (every parameter is of a named subtype). > > > > e.g., > > > > type Action is procedure (This : in Something); > > type Predicate is function (This : in Something) return Boolean; > > > > Is that the idea? > > Yep > > > The conformance rules for parameters of these types would then have to > > be more like the matching rules for generic formal subprograms, or > > subprogram renamings. That is, you don't declare a function to be of > > type Predicate (per the example), > > Well, something like > > Foo : constant Action := > declare > ... > begin > ... > end Action; -- or end Foo; ? > > looks a bit indigestibe. A lot indigestible. > Something in the package instantiation / type > extension style: > > procedure Foo is new Action with > ... > begin > ... > end Foo; > > seems also clumsy. No, what I had in mind was a contract model with matching rules, e.g. procedure Foo (X: Something); would match a formal of type Action in the example. > > > you declare a function in the normal way and then it matches a > > subprogram of type Predicate. Right? > > > > That _is_ a bit of a stretch to the philosophy of the type system. > > The essential idea of a type is that it's a template for the creation > > of objects. Every type in Ada is an object type; this breaks that > > regularity. This would be a type that not only doesn't have objects > > as its instances, it doesn't have instances at all! It's just a > > vehicle for carrying around a profile. So from that perspective it's > > a little bizarre. > > Such kind of argumentation seems to be valid against T'Class too. Kind of, but not really :-). Objects of T'Class really are _objects_, even if you can't declare an object to be of type T'Class. Classwide types are formally defined to be indefinite, as are unconstrained types. So you can't declare an object of type T'Class, for the same reason that you cannot declare an object of type String. That doesn't make String any less of a real object type. Ada95 defined a new kind of access type, the access-to-subprogram type. It's a real object type with real object values, even if the value is a pointer that denotes something other than an object. You propose an altogether new kind of type that is unprecendented in that it does not describe objects, but subprograms. It is so unrelated to the concept of an object type that it doesn't seem legitimate to even call it a type, except to make the nice syntax for declaring subprogram parameters! The tail wagging the dog, in other words. The concepts of type and object are inseparable. To have subprogram types make sense, as a starting point you would have to make subprograms be first-class objects (not just a new kind of parameter), and that would be a much different language than Ada. I guess you could make the same argument for the concept of "pointer", but I think empirically Ada95 shows that there's enough wiggle-room in the idea of "pointer" to accommodate access-to-subpgrogram types. > > > Another idea that went around, I think during the Ada9x process, was > > that of a "limited access" type. This is a real object type, so it's > > more consistent with the rest of the Ada type system. Limitedness > > solves the accessibility problem for downward closures. > > The idea is interesting but, IMO, it is generally inconsistent to have > pointers and have no types they point to. Well, access-to-subprogram is here to stay in Ada, whether you like it theoretically or not :-) :-) :-). "limited access", at least, would be a mild extension of what we already have in Ada95. I'm suprised you object to "pointer denoting something other than an object" (which, I repeat, we already have) more than you object to "type describing something other than an object". And access-to-subprogram types are useful for more than just passing as parameters (precisely because they are real object types). In terms of the machine model, pointer to a subprogram makes sense even if subprograms are not objects (and hence not instances of a type). Subprograms have an address -- or a descriptor, or something that can be used as an aliasing reference. If they don't, then they certainly cannot be passed as a closure! (For instance, you couldn't pass an inline subprogram or an intrinsic subprogram as a closure). Cheers, Mark Sent via Deja.com http://www.deja.com/