Re: Q: access to subprogram

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

Ken Garlington <garlingtonke@lmtas.lmco.com> writes:

>Richard A. O'Keefe wrote:
>> 
>>         Ada (using generic instantiation)
>>                 compiled with gnatmake -gnatp -cargs -O4
>>                 Size: 94 lines.

>I don't know how to read the gnat command lines, so could some one tell me
>if this means all exceptions are suppressed?

If I may quote from "gnatinfo.txt"
    To disable constraint checks, compile the program with th
    "-gnatp" option.  This is equivalent to having Pragma suppress
    applied to everything.

So yes, it does suppress everything.  -O4 is high optimisation level.

>Also, is source line size being given here as a measure of efficiency?

Don't be ridiculous, of *course* not.
The number of source lines required to express the same algorithm
naturally is an inverse measure of EXPRESSIVENESS, and has no
intrinsic connexion whatsoever with efficiency.  Why would you imagine
otherwise?  The sole measure of efficiency I proposed is TIME.

>What were the other measures compared to the alternatives
>(readability, reusability, etc.)?

Obviously, if it takes you more lines, it's likely to be harder to read.
I have no objective measurements of readability.  I believe that I am
equally familiar with all four languages (I have, and have studied hard,
the standards for all of them, and have written a fair amount of code in
all four).  In this case:

	Scheme is the most readable.
	Pascal comes close; no warping to fit the language.

	The C code is shorter, but it has some nasty internal coupling,
	so I rank the Ada code (all connections explicit) as more
	readable (though longer) than the C.

As for re-use, where I can be objective:

	Scheme is by far the most reusable, having no constraints
	on reuse at all.

	The Pascal code is cut-and-paste reusable; in Turbo Pascal or
	Think Pascal or ISO Pascal Extended the integration code could
	be in a unit/module.

	The Ada code is as reusable as the Pascal code, in the sense of
	requiring no modifications for reuse, but has higher reuse costs.
	(It takes more source code to effect reuse, and generates more
	object code).

	The C code was not written for re-use.  The need to explicitly
	simulate funargs by passing environment pointers pushes up reuse
	cost; unlike the Scheme and Pascal code you cannot combine the
	integration functions with *existing* real-valued functions but
	must write glue code.


>> I guess Scheme running 3 times faster than Ada or Pascal is not "intuitive"
>> for many programmers.

>It's certainly not intuitive to _me_. However, I would certainly have no problem 
>with a statement that a particular Scheme toolset might generate code that is 
>three times more efficient than an Ada _toolset_, for a given host/target 
>platform. (Do we really believe GNAT is the most efficient Ada compiler available, 
>for example? I keep reading that not all optimizations have been implemented in 
>GNAT yet...)

For sure.  Stalin has a fair bit in common, I think, with VORTEX, with
the Self compiler, and with Stanford's FUSE.  The common factor here is
tools that start with very high level languages and optimise the heck out
of them; there are analyses and transformations that they perform which I
expect Gnat will _never_ perform.  Partly this is because they deal with
simpler languages.  For Ada, I think it is more important to get tasking
absolutely right than to perform aggressive optimisations.

Note also that in a previous thread in this group I was pleased to report
that GNAT's time for a certain numerical program was close to the time
from SPARCompiler Fortran 77.  Whether or not GNAT is the best, it is
pretty darned good.

But please, don't attack a proposition your interlocutor never defended.
Gnat is the best Ada compiler *I've* got, that's all.  So far I have tried
this example in
	Clean 1.0		-- not the latest version
	Gambit 2.2.2		-- pretty recent, but maybe not the latest
	Think C 5.0		-- far from the latest version
on the Mac
	Gnat 3.04		-- not the latest version
	SPARCompiler C 4.0	-- is the latest version
	SPARCompiler Pascal 4.0	-- is the latest version
	Gcc 2.7.2		-- probably not the latest any more
	Stalin 0.6		-- latest generally available
on an UltraSparc.  Why these versions?  Because that's what I've got.
That's all.

Remember:  I am not interested in establishing which _language_ is the
best.  My sole concern was to provide an example showing that the
restrictions on procedure parameters which make my example *impossible*
to write directly in Ada 95 are not *necesary* for efficiency.  This
does not, unfortunately, prove that it would be easy for _any_ Ada
vendor to support Algol-style funargs, still less that it would have
been affordable for _every_ Ada vendor to do so.  ALL my example can
accomplish, and I believe it does accomplish this, is to show that
Algol/Pascal-style funargs are fully consistent with more efficiency
than I can currently get from a good Ada compiler.
-- 
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.