Re: intrinsic modules ...

[Paul Brook <paul at codesourcery dot com>]

[sorry about the delayed response, I'm a bit behind on gfortran mail]
On Monday 06 September 2004 17:23, Lars Segerlund wrote:
>  Hi again,
>
>   I have not had much opportunity to do some work on gfortran in a while,
> but now I have started to get down to it.
>
>   I have been all over intrinsic modules, and especially the C binding
> module.
>
>   What I have come up with is one of two approaches, the first one is to
> treat intrinsic modules differently than ordinary modules, ( ie. basicly
> make code to explicitly handle intrinsic modules ), and the second one is
> to somehow use the regular code for modules, ( although the modules them
> self might have to be a bit special, perhaps even special parsing for them
> basicly things could be done with the default module format ), and simply
> encode a lot of the functionality to be handled at resolve time.
>
>   The above might not be 100 % correct but the general lines of thought
> should be possible to follow, ( I am really tired right now, sorry ).
>
>   Right now I favour the second approach, whats the opinion of the people ?
> :-) ...
>
>   I have been looking at using the code for regular modules explicitly
> during compiler build time to generate the module files i want, ( I call
> them .imod :-) ... ) does this seem as an acceptable solution ? The big
> bonus is that I should get the name resolution right, ( as long as the
> ordinary modules work ).
>
>  The reason for asking is that I don't want to start off on the wrong track
> or on a solution which is unacceptable on the whole.

I have two worries about your .imod strategy:
- Where are these .imod files going to be installed, and how are we going to 
find them at runtime? An installed gcc should be relocatable.
I don't see how having them as discrete files gives us any benefit over 
somehow building them into f951. It does potentially introduce several more 
failure modes.
- Many of the functions in intrinsic modules are magical polymorphic things 
that aren't representable by normal methods (as are many of the existing 
intrinsics). Presumably you've figured out how to wedge these into the module 
reading/writing framework?

Paul