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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,99ab4bb580fc34cd X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Q: access to subprogram Date: 1996/07/09 Message-ID: #1/1 X-Deja-AN: 167406067 references: <4rb9dp$qe6@news1.delphi.com> <4rr5tu$sap@watnews1.watson.ibm.com> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-07-09T00:00:00+00:00 List-Id: In article <4rr5tu$sap@watnews1.watson.ibm.com>, Norman H. Cohen wrote: >The size of a display for a given procedure IS known at compile time. True (assuming you don't "really" support separate compilation of subunits). But the size of "THE display" is the max of all those. This is not known at compile time, but at link time. To package up a display along with the corresponding procedure (when 'Access is done), you have to either know that max size, and copy that much into a compiler-generated variable, or else you have to manage varying-size displays (and copy THAT much) -- note that the caller who does P.all(...) doesn't know where P came from, and so either has to be TOLD the size of P's display, or always use the max. Or, I suppose you could simply say that the max is 10, and forbid nesting more than 10 levels deep. Perhaps a reasonable restriction, but I hate having arbitrary restrictions like that, if it's feasible to avoid. Any of the above are quite implementable, but I think that static links are clearly simpler for the implementation. >... I viewed the inclusion of downward >closures as the REMOVAL of an arbitrary restriction. Me, too. This is an illustration of Robert's point about simplicity. We were all shouting for more simplicity, but everybody had their own idea of simplicity (simple to describe in the RM vs. simple to implement vs. simple to learn for a beginner vs. simple to use for an experienced programmer vs. etc etc etc). >... The decision was >not made in ignorance. Bill Taylor had made what I considered an >irrefutable case for downward closures, showing how much easier it would >be to write iterators if downward closures were allowed. It came down to >a conflict between the interests of Ada programmers and the interests of >a minority of Ada implementors, and in this case the interests of the few >implementors using displays prevailed.) Well, to be fair, if the implementers can't implement, the users are kind of stuck. Probably not true in this particular case, but in the general case, you don't want to just add every feature anybody wants. If the compiler gets too big, it gets too buggy -- no matter how much money you spend on it, apparently. - Bob