Continue researching gotchas, designing the transformational process, and implementing it.
Specific issues to resolve:
USEprocessing take place?
This gets into the whole issue of how
g77 should handle the concept
I think GNAT already takes on this issue, but don't know more than that.
Jim Giles has written extensively on
about his opinions on module handling, as have others.
Jim's views should be taken into account.
Actually, Richard M. Stallman (RMS) also has written up some guidelines for implementing such things, but I'm not sure where I read them. Perhaps the old firstname.lastname@example.org list.
If someone could dig references to these up and get them to me, that would be much appreciated! Even though modules are not on the short-term list for implementation, it'd be helpful to know now how to avoid making them harder to implement them later.
g77command become just a script that invokes all the various preprocessing that might be needed, thus making it seem slower than necessary for legacy code that people are unwilling to convert, or should we provide a separate script for that, thus encouraging people to convert their code once and for all?
At least, a separate script to behave as old
g77old, might ease the transition,
as might a corresponding one that converts source codes
These scripts would take all the pertinent options
to take and run the appropriate filters,
passing the results to
g77 or just making new sources out of them
(in a subdirectory, leaving the user to do the dirty deed of
moving or copying them over the old sources).
CHARACTER(or Hollerith) constants?
Knowing what other compilers provide would help.
I've asked email@example.com for input on this. Not having to support these makes it easier to write the new front end, and might also avoid complicated its design.
The consensus to date (1999-11-17) has been to drop this support. Can't recall anybody saying they're using it, in fact.