Re: Q: access to subprogram

[rogoff@sccm.Stanford.EDU (Brian Rogoff)]

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