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-12 12:44:08 PST Path: supernews.google.com!sn-xit-03!supernews.com!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: mark_lundquist@my-deja.com Newsgroups: comp.lang.ada Subject: Subprogram types vs. "limited access" (was Re: Do we need "Mission-Critical" software? Was: What to Do? Date: Fri, 12 Jan 2001 20:29:55 GMT Organization: Deja.com Message-ID: <93npfn$13d$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> NNTP-Posting-Host: 130.213.200.208 X-Article-Creation-Date: Fri Jan 12 20:29:55 2001 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) X-Http-Proxy: 1.1 x63.deja.com:80 (Squid/1.1.22) for client 130.213.200.208 X-MyDeja-Info: XMYDJUIDmark_lundquist Xref: supernews.google.com comp.lang.ada:3968 Date: 2001-01-12T20:29:55+00:00 List-Id: 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: > > Java wanted to get rid of pointer-related bugs. Unfortunately, you > > kind of have to have pointers! > > Yes, but rare. I meant for linked data structures... you need by-reference semantics, or in a by-value language you need pointers. It's hard to believe Gosling et al would not see past the C conception of pointer=address=integer. For whatever reasons they went with a by- reference design. Who can say... > 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? 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), 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. 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. Bob Duff wrote an AI on this. The verdict was that the ramifications were negligible for implementations that used static links, but would be quite burdensome for implementations that use displays, so the idea was rejected. I wonder, are there any (current) Ada implementations out there that use displays for nested context? I'm not a compiler expert; what factors constrain the choice of static link vs. display? Are there aspects of the target that favor one or the other? I just don't know... Other access types could be limited as well, not just access-to- subprogram, and limited access is useful for other things besides downward closure. I'd like to see this feature added. -- mark Sent via Deja.com http://www.deja.com/