 |
 |
I wrote: > > Yet another way that wasn't explicitly on Richard's list (although it's > > subsumed under his fourth alternative): > > > > Write as much of the guts of each of your list-handling routines as can > > be written without reference to types or kinds, in any way (not even > > constants). > > > > Put each of these "guts" in a separate file, one for each routine. > > > > Write a new routine for each new type, complete with the appropriate > > type specifications and any type/kind-specific stuff, and then "include" > > the appropriate "guts" file. If you need to put type/kind-specific stuff > > in the middle, you may need to chop the "guts" file into pieces. Use > > parameters in the header for type/kind-specific constants. and Philip Helbig wrote: > Something similar could/should be used for generic routines? Another > place where include is needed? Could something similar to ELEMENTAL be > introduced to avoid duplication of code for different types, as > ELEMENTAL did for different shapes? I liked the idea of dummy arguments for modules, with actual arguments specified on USE statements. Like procedure dummy arguments, module dummy arguments could be module actual arguments on USE statements. I think this requires the compiler to invent a new module for every combination of actual arguments. I had in mind that actual arguments could be types, but to be parallel with current work on parameterized types it would also make sense to allow integers, and distinguish whether a particular one is used for KIND or NONKIND specifications. I don't know the ramifications for implementors, but I have been told that a similar facility in Ada caused the developers significant delays. Maybe what I'm proposing here is simpler than what's in Ada. In any case, it's not going to happen in the next standard -- at least I'm not going to propose it. If anybody else wants to propose it, be prepared to be reminded that the requirements phase has been over for three years. Best regards, Van Snyder %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%