Re: [Patch, Fortran] Calling type-bound procedures

["Paul Richard Thomas" <paul dot richard dot thomas at gmail dot com>]

Daniel and Tobias,

First, please accept my congratulations for a truly magnificent bit of
work!  I know that Daniel has done most of the labour but, in my
absence, Tobias has done an excellent job with the reviews, testing
and standard control.

Secondly, my apologies for not coming back to you last Sunday, as
promised.  The removal ate into the whole day and there was no time
left for gfortran.  Anyway, I am in place now and back at work.  I
will build up to the normal level of contributions over the next few
weeks.

On Wed, Aug 27, 2008 at 11:16 PM, Tobias Burnus
<tobias.burnus@physik.fu-berlin.de> wrote:
> Hi Daniel,
>
>> this is the cleaned-up version of my patch to allow for calling
>> type-bound procedures posted yesterday including a ChangeLog.
>
> As a small thing: I think one should update dump-parse-tree.c; I think
> everyone tends to forget it and it is almost never used.

Absolutely right!  In fact, I use -fdump-parse-tree a lot and it
certainly needs all sorts of f2k features to be added.  One example is
EXTENDS!

I wonder if we will not need to change the format?  I guess that the
additional features will make the dump seriously incomprehensible:-)
>
>  * * *
>
> I like your patch. However - thanks to NAG f95 - I just realized that we
> currently cannot implement PASS in a standard conforming matter. The
> reason is:
>
> C453 The passed-object dummy argument shall be a scalar, nonpointer,
>     nonallocatable dummy data object with the same declared type as
>     the type being defined; all of its length type parameters
>     shall be assumed; it shall be polymorphic (5.1.1.2) if and only
>     if the type being defined is extensible.
>
> The problem with PASS for all type-bound procedures and for procedure-
> pointer components in non-SEQUENCE, non-BIND(C) procedures is the
> following: The type needs to by polymorphic, i.e. instead of
>
>  TYPE(mytype) :: dummy_arg
> one needs
>  CLASS(mytype):: dummy_arg
>
> Thinking about it, it makes sense: Unless the procedure is overwritten,
> the type%inherited_proc() won't work. (I have not checked what happends
> currently.)

I suggest that we continue to allow this temporarily and emit a
warning.  That way, all the hooks are there and we can correct it as
soon as......

>
> The big question is now how to handle this? For proc pointer comps with
> SEQUENCE and BIND(C) [assuming PASS is allowed for them, I have not
> checked] the current machinary can be used, but for an ordinary,
> extensible type? Shall we abort in this case with "Sorry, not
> implemented"? Too bad that Paul has not managed to recreate his CLASS
> patch :-(

It is now partially recreated.  Give me a few days and I might be able
to offer something useful that will at least allow this to work.

>
> Somehow type-bound procedures without PASS loose a lot of their
> usefulness. Except for this point I think the patch is OK.

I agree.

+      /* XXX: Should I replace the gfc_error_now above by a gfc_error?  This
+        should be possible by some (not much) effort with returning an
+        optional gfc_try FAILURE here.  */

I think that is what you should do.

Other than this - OK for me.

Paul

-- 
The knack of flying is learning how to throw yourself at the ground and miss.
 --Hitchhikers Guide to the Galaxy