Re: Q: access to subprogram

[ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe)]

rogoff@sccm.Stanford.EDU (Brian Rogoff) writes:
>Idiom in the sense of "pattern",  an interesting interaction with other 
>features of the language they appear in.

I didn't say that I didn't grasp the *meaning* of the word "idiom" in
this context, only that I didn't grasp the *intent* of the question.

The point is that this is such a basic and quirk-free building block
that you don't think in terms of "idioms" for it any more than you
think in terms of there being special idioms for assignment statements
or while loops.

>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.

Concerning performance models:
    I spent this afternoon (when not talking to students) taking the
    integration example and beefing it up to the point where it would
    plausibly take a reasonable amount of time.  I produced three
    versions:

	Ada (using generic instantiation)
		compiled with gnatmake -gnatp -cargs -O4
		Size: 94 lines.

	Pascal (using nested procedures passed as parameters)
		compiled with SPARCompiler 4.0 pc -s -native -O4
		Size: 57 lines.

	Scheme
		compiled with stalin -copt "-O4" -d -On -dc
		(this compiles Scheme to C, then uses gcc as a back end)
		Size: 40 lines.

    Guess what:  the Pascal and Ada versions both took 18 seconds on
    a "sunu4, Ultra-Enterprise", whatever that is, while the Scheme
    version took 6 seconds.
I guess Scheme running 3 times faster than Ada or Pascal is not "intuitive"
for many programmers.

To be really honest, I *thought* I knew what the cost model for generics
was, but have heard repeatedly in this newsgroup that I shouldn't think
of generic instantiation as macro instantiation.

>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.

Yes, I do know.  The point I am defending, which has been made before by
others, is that "access to procedure" is one thing, and "procedure as
parameter" is another, and that you don't *need* to allow access to
procedure in order to either implement or use procedure as parameter,
and you particularly don't need to allow restrictions related to the
former to limit the use of the latter.

>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. 

Exactly so.  Although the code generated for the Scheme version of this
program uses stack allocation and does (and _can_ do) no garbage collection.

>   <... excellent example of how composition of functions leads to concise 
>        multidimensional integrator from single dimensional version
>        sadly deleted >

>>  Most of all, consider the effect on program style and clarity.

In this particular case (big is bad).
	Scheme : Pascal	: Ada
Size	4      : 6      : 9
Time	1      : 3      : 3

DO NOT EXTRAPOLATE THE SIZE OR TIME NUMBERS TO OTHER KINDS OF PROBLEMS.

>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.

I must have missed the discussion of how this would affect shared generics.
I am all in favour of shared generics, but surely generics cannot _always_
be shared, so there's always a fallback strategy, or have I misunderstood?

>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.

This is misleading.  They use *languages* in which there are few or no
restrictions on closures.  This does not mean that every *program* using
closures in these books or in day-to-day functional programming uses
upward closures all over the place.

>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 ;-).

Well, if you want object orientation, there's O'Caml, which is supposed to
be pretty good.  
-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.