Re: Type-bound procedure and procedure pointer component calls

["Janus Weil" <jaydub66 at googlemail dot com>]

Hi Daniel,

> I've started playing around with calling type-bound procedures, and here's
> another, more conservative approach that could do well (maybe the gfc_callee
> idea is somewhat "cleaner" but this one will be much easier to integrate
> into the existing code):

first off: this approach sounds pretty much like what I was thinking
of. I have a few comments, though.

> Add a new ref-type REF_PROC or extend REF_COMPONENT with an attribute to
> hold an actual arglist; then in match_varspec, if a component symbol is
> found that is in the type-bound procedures namespace, parse an arglist
> following it and build such a REF_PROC:
>
> WRITE (*,*) val(1)%tbp_function (42)
>
> will become
>
> EXPR_VARIABLE(val) -> REF_ARRAY(1) -> REF_PROC(arglist(42), gfc_typebound*)

Sounds good. Alternatively the arglist could be stored in the top
level gfc_expr, which already has a field for it
(expr->value.function.actual). Then I think we also need a new
expression type (EXPR_SUBROUTINE?) for the case that the TBP/PPC is a
subroutine. For functions we can probably reuse the existing
EXPR_FUNCTION.

> During resolution, we can transform such an expression easily into an
> ordinary function call; the passed-object will be given by the expression
> itself with the last reference removed, and the other things needed for the
> call (the binding-target procedure and the arglist) are in the REF_PROC.

Ok. However, this "transforming to ordinary function call" does not
work for PPCs of course. There we need dynamic calling, which will
also be necessary for TBPs later to have fully dynamic polymorphism
(once the other OOP bits are in place). So, at *some* point this will
have to be implemented in a dynamic way. The question is: Should we
already do this now, or rather start with a static transformation at
resolution stage? The advantage of the dynamic approach would be that
it's more or less the same for both TBPs and PPCs, so that we
hopefully need only one implementation. And we wouldn't have to change
it later for full OOP.

> For CALL's, we could add a new field
>
> gfc_expr* tbp;
>
> to gfc_code.  If not NULL it will hold such a reference-expression as above
> encapsulating the TBP-call.  Once again, during resolution this will be
> transformed into an ordinary CALL of a SUBROUTINE.

Do you think an extra field is necessary? gfc_code already has two
gfc_expr fields ("expr" and "expr2"), none of which is being used for
CALL. And the type of the expression will in any way be indicated by
expr->expr_type (EXPR_SUBROUTINE/EXPR_FUNCTION/etc).

Maybe it would be a good idea to start with a patch that changes the
way that ordinary functions and subroutines are called (by using
gfc_expr instead of gfc_symtree), so that this can more easily be
extended to TBPs and PPCs.
Alternatively we could leave the implementation like it is, but then
TBPs/PPCs will not fit in as nicely ...

> I think this approach should at least work basically for parsing PPC calls
> also if REF_PROC is extended as needed.  From resolution onwards of course
> PPC's must be handled others than TBP's that can be transformed into
> ordinary calls.

See my comments above. I think it would be nice handle both in a
similar (dynamic) way also beyond resolution stage.

Maybe some of the more experienced gfortraners could try to comment on
all of this. I'm not sure if I'm overlooking all the consequences of
our design decisions right now.

Cheers,
Janus