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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,99ab4bb580fc34cd X-Google-Attributes: gid103376,public From: rogoff@sccm.Stanford.EDU (Brian Rogoff) Subject: Re: Q: access to subprogram Date: 1996/07/22 Message-ID: X-Deja-AN: 170147962 references: <4rb9dp$qe6@news1.delphi.com> organization: /u/rogoff/.organization reply-to: rogoff@sccm.stanford.edu newsgroups: comp.lang.ada Date: 1996-07-22T00:00:00+00:00 List-Id: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes: rogoff@sccm.Stanford.EDU (Brian Rogoff) writes: [about nested procedures as parameters of other procedures] >I guess I would ask Pascal programmers how useful they found this, and whether >any interesting idioms emerged which used this feature. As an old Algol/Pascal programmer, I would answer "very useful". I don't quite grasp the intent of the "any useful idioms" question. Idiom in the sense of "pattern", an interesting interaction with other features of the language they appear in. In Ada, for example, the idiom to simulate mixin inheritance involves parametrizing a mixin type with its enclosing type through access discriminants. Other languages might have other features to do the same thing. Procedures as parameters are an abstraction mechanism. Hen's teeth, even Fortran has them. Why? So you can build abstractions like "integrate over an interval"; "Monte-Carlo integration in N-dimensional space"; "find the minimum of a function over an interval"; "find the mimimum of a function in N-space" (Nelder-Mead, for example); "solve ODE"; ... Scheme was my first language. I like it, and I understand the benefits of closures and lazy evaluation and such. But Ada is designed to have a fairly intuitive performance model for most operations, unlike Scheme. Also, as I am sure you know, Ada 95 has access to subprogram, which can be used to implement the numerical routines you describe, albeit not as cleanly as you do. By "procedure parameters", I take it that you mean the general case of Pascalish nested procedures, but not Scheme or ML closures, which require more sophisticated (usually garbage collected) runtimes. <... excellent example of how composition of functions leads to concise multidimensional integrator from single dimensional version sadly deleted > Yes, the version with generics isn't as pretty as the version with downward closures in Pascal, even without your extension. I could code the same thing with other Ada 95 features, but I agree that for some things this functional style is very appropriate. Most of all, consider the effect on program style and clarity. Many people, of whom I am one, consider passing procedures as parameters a *fundamental* control structure (really fundamental; people in this camp like to use it as a primitive to explain IF), and while it is possible to program without it, so would it be possible to program in a language with no FOR statements or where no expression was allowed to have more than one operator or where there was no automatic storage allocation. All of these are *possible*, but why make programming any harder than it has to be? I am not the right person to argue against this, since I think it should have been part of the language, but there are arguments about the effect of this feature on implementations using shared generics, and about the impact on existing implementations. At least one company dropped its Ada efforts, ostensibly for the reason of added implementation burden. I think all issues of the interaction of the implementation of downward closures with other parts of the language would have to have been closed for this argument to have been won. As I said above though, I agree that this approach is also easier to understand (more readable!) than the generic approach. In fact it is hard to imagine a more understandable approach... >Maybe a few more useful examples, and a consensus on the implementation >issues would enable this issue to be reopened in the future. Procedures as parameters have been around since the late 1950s. There are many thousands of commercially important Fortran programs and libraries using them. There are libraries full of books about the functional programming paradigm and the importance of procedures as a (not "the", "a") tool of abstraction. Almost all of the books on functional programming use full "upward" closures, which are not quite what Ada would get if these get added to GNAT say. There are also books around on simulating the features of functional languages with "functor" objects. I find these idioms a little clumsy, but I think that I'll wait a while to pronounce judgement. It may be that as I get more used to Ada I'll find those and other methods more palatable... Or maybe they'll all look like Rube Goldberg devices and I'll keep wishing it were different. But for me the choice is not between Ada 95 and Clean or ML, but Ada 95 and C++. Ada 95 still looks very good ;-). -- Brian