Re: abstract sub programs overriding

[adam@irvine.com (Adam Beneschan)]

Simon Wright <simon@pushface.org> wrote in message news:<x7vu11096nc.fsf@smaug.pushface.org>...
> Marius Amado Alves <amado.alves@netcabo.pt> writes:
> 
> > It's very simple, really: you can only call concrete, and of course 
> > available, operations.
> > 
> > In your program you had an abstract (not concrete) Generate (for a
> > 'root' type), and a concrete, but not available Generate (for a
> > derived type). The concrete Generate was not available (at the point
> > of the call) because it was declared in the private part of a
> > separate unit. So the first was available but was not concrete, the
> > second was not available, GNAT went for the only available one, and
> > naturally failed, mumbling whatever GNAT mumbles when it tries to
> > call an abstract operation.
> 
> I'm sure this explanation isn't right. The pointer concerned is to a
> classwide type, and the contract says that any actual Element_Record
> has a concrete (callable) Generate operation.
> 
> It would be easy to construct a program where Main had access to an
> Element (the classwide pointer) but not to Generator.Declarations
> (where the concrete type is defined).
> 
> I agree that putting it in the private part is perhaps misleading, but
> that doesn't mean it's wrong -- we need a lawyer!

Putting it in the private part doesn't matter, since a dispatching
call can still reach it (3.9.2(20), 7.6.1(3)).  In this case, the
abstract Generate that Type_Decl_Record inherits is overridden with a
nonabstract version (in the private part of Generator.Declarations);
this nonabstract version is then inherited by
Discrete_Type_Decl_Record, and later by Enumerate_Type_Decl_Record. 
This last inherited subprogram is the one that should be called when a
dispatching call is made to Generate on an object of type
Enumerate_Type_Decl_Record.

In fact, I think the whole discussion about abstract vs. concrete
subprograms is barking up the wrong tree.  As far as I know, there
should never be a runtime error for an attempt to call an abstract
subprogram.  The language rules ensure that this can never happen,
i.e. that whenever you call a subprogram (either directly or via
dispatching), that subprogram will be concrete (as opposed to C++,
which I believe does not guarantee this).  This is accomplished by
disallowing objects of an abstract type and direct calls to an
abstract subprogram, and, most importantly, by disallowing primitive
abstract subprograms of a nonabstract tagged type, and by requiring
that abstract subprograms be overridden when a derived type is
nonabstract.

I would expect the "access check" error to refer to an accessibility
level problem (although I can't speak to what other errors might cause
GNAT to say "access check").  Since all the access types in this code
are library level (none is declared inside a subprogram), it does seem
quite weird that this error would be showing up.

                                  -- Adam