Re: Access to subprograms

[stt@spock.camb.inmet.com (Tucker Taft)]

Norman H. Cohen (ncohen@watson.ibm.com) wrote:
: In article <FRED.95Mar20101937@play.uno>, fred@play.uno (Fred Hosch) writes: 

: |> From my casual and uninformed reading of the RM, it
: |> seems that something like "+"'Access is legal, even,
: |> heaven forbid, for a predefined instance of "+".

: It's prohibited by RM95 6.3.1, paragraphs 4, 7, and 11.  (Predefined "+"
: operators have convention Intrinsic, and 'Access is prohibited for
: subprograms with this convention.)  Instead, you can write

:    function My_Wrapper (Left, Right: Integer) return Integer is
:    begin
:       return Left + Right;
:    end My_Wrapper;

: (or similarly for some other numeric type) and write My_Wrapper'Access.

: But why "heaven forbid"?  It would have been easy for the compiler to
: generate a wrapper function like this automatically and invisibly, and it
: strikes me as a gratuitous nuisance to make the programmer go through the
: ritual.  It also makes the language less uniform.

.. because generating things automatically and invisibly is contrary to
the philosophy of a systems implementation language, IMHO.  Invisible
things interfere with a systems programmer's ability to estimate
accurately the relative time and space performance of various features.
For example, would it be appropriate to use "+"'Access multiple times,
or would this result in multiple copies of such an "invisible" wrapper?

The more things happen "invisibly," the more the time and 
space performance is compiler-dependent, rather than being
dependent on the intrinsic properties of the source program and the 
target machine.

[By the way, this is one reason I don't like Ada's "holey"
enumeration types, since they create hidden compiler-dependent 
time and space overhead in surprising places.]

Predictable performance was an important goal of the Ada 95 features;
occasionally this means the programmer has to work a little harder.

: Norman H. Cohen    ncohen@watson.ibm.com

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.