Re: Subverting 'Access for Sub-programs

[Brian Rogoff <bpr@shell5.ba.best.com>]

On Fri, 13 Aug 1999, Robert Dewar wrote:
> Really what we need to do at this stage is to try to get some
> idea of what the Ada user community wants. GNAT users are not
> the best source of help here, since the problem is already
> completely solved in GNAT (although of course not in a portable
> manner!)

I think GNAT users are as good a source of help as any other
implementation bound subset of Ada users. At least GNAT users 
can speak from experience as to how useful Unrestricted_Access 
is, what contexts they use it in, etc. I can tell you that I much 
prefer it to using generics to simulate downward funargs, though I almost
always use generics because that approach is portable between compilers.
From the question which started this thread, I presume many people agree. 
I still think generic subprograms are useful for type checking, like 
the "where clauses" of CLU and Theta, but as downward funargs they only 
provide a clumsy workaround, IMO of course :-).

> For users of other compilers, how much of a restriction is it
> to have access-to-procedure have the limitations of the current
> Ada 95 design, that is the question.
> 
> I certainly know, as I have previously noted, that we make
> extensive use of Unrestricted_Access in the GNAT runtime (there
> are well over 100 instances in gnatlib). This is certainly not
> typical. First, a lot of it is low level system type code,
> second, you tend to use features that are available if it is
> the easiest way of doing things, and it does not always mean
> that you couldn't manage OK without them :-)

Well, since much of the philosophy of Ada is about readability,
maintainability, reusable libraries, etc., the fact that the 
use of these GNAT extensions makes programming easier is telling!

I certainly wouldn't abandon Ada over this deficiency, but given the 
fact that Ada has nested functions and lexical scope, the absence of 
direct support for downward funargs is very irritating. 

-- Brian