Paul Isaacs wrote:
I noticed that imports done outside the interface-specification-part are not dependency checked by --automake. This creates problems for first time gnu pascal uses such as myself.
I started placing imports outside the interface-specification-part to avoid circular dependencies and it took a while to understand that --automake was no longer finding the import dependencies.
Hmm, there are bugs with automake but I am nit sure if your description is accurate.
I also assumed that the reason for the, rather awkward, multiple interface capability was to get around the module circular dependency problem. Ada resorted to the kludgy 'limited with' workaround.
multiple interface capability is specified in ISO standard. AFAICS it is logical way to give good control over what gets exported. It has nothing to do with dependency problems.
Gnu pascal seems to have resorted to the import 'in' workaround.
That is different problem: how to map interfaces to modules and modules to files. At the time standard was written there were voices that files are obsolete and source code should be stored in databases. Database could easily store not only code but also mappings between interfaces and modules (and you could retrive module source given its name). So apparently standard committee decided that problem of mapping interface name to interfaces is easily solvable.
However, having filenames in the source code does not seem to me to be a good idea.
There is no need for filename in Pascal file if your build system knows which files should be compiled.
Would "import modulename_interfacename" work?
The first '_' character would take on special meaning but the change would be 10602 specification compliant and having the module name and interface name combined into one identifier would eliminate the need for file names in the source code.
No. Your proposal violates ISO-10206: underscore is legal part of interface and module name. And it does not solve anything: AFAICS your modulename really means name of file containing the module. So you still put put filename inside Pascal files, just instead of using nonstandard syntax (which guarantess that there is no conflict with standard use) you try to hijack standard syntax (which have alredy defined and different meaning). It is possible to modify your proposal and be kind of compliant: namely forbid module names containing underscores and require that interface names always contain underscores and first part of interface name is the same as module name. But I see no point: currently GPC can handle almost all Extended Pascal module constructs (that is accepts standard code without any changes). Restrictions on module and interface names while defensible from language-lawyer point of view would mean step back.
BTW: In the past I have spent some time trying to make better automake. Now, I would say that automake has one nice point: it reuses parser already present in the compiler. But otherwise it has serious problems. So it would be better to have "parse for dependencies" mode in the compiler. Or use separate parser, as 'gp' utility is doing.