Hello,
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.
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.
Gnu pascal seems to have resorted to the import 'in' workaround. However, having filenames in the source code does not seem to me to be a good idea.
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.
Regards,
Paul Isaacs
On Mar 6, 2016, at 9:07 AM, Paul Isaacs paul@redpineinstruments.org wrote:
Hello,
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.
GPC’s —automake has problems so back in late 2005 Frank Heckenbach created a new dependency checking analyzer and auto-building driver progeam for GPC called ‘gp’. You can find the source code for gp at http://www.gnu-pascal.de/contrib/frank/gp-0.61.tar.bz2. (There is a README file in the tarball that give directions in using gp instead of gpc —automake.)
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.
The gp driver program correctly separates interface-specification-part import dependencies from implementaion-part import dependencies. In those cases where an implementation-part import creates a source code “whole” file circular dependency, gp correctly avoids “whole” file circular dependency problem by first having gpc do only an interface-specification-part compilation of the necessary source code files and (if successful) followed by gpc doing only an implementation-part compilation of the necessary source code files.
Note: In a few rare cases (which I haven’t been able to distill down to a good reproduceable error test case) gp might be slightly off of “what needs recompiling” in a partial recompilation after a source code change recompilation and you’ll get something like an “interface x needs recompiling” error when compiling a using/importing implementation-part. If you encounter that sort of problem, the fix is just doing a clean/from scratch build of all your program’s source code.
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.
Gnu pascal seems to have resorted to the import 'in' workaround. However, having filenames in the source code does not seem to me to be a good idea.
Actually, GPC’s import 'in’ workaround isn’t for solving circular dependency problems; rather, it is used to explicitly tell the compiler which source code file something can be found instead of using the default implicit mapping of unit/module “name” to filename “name”.p[.pas][etc] for specifying the file location.
Would "import modulename_interfacename" work?
Really doesn’t change the problem you’re trying to solve. You’re still left with where in the heap of files do I find the “name” and the correct one at that of all the potential occurrences of “name” in the heap.
A lot of different schemes for that problem have been tried over the years and all but a few end up having a filename explicitly or implicitly embedded in the mapping of “name” to its “found” location somewhere in the scheme.
Gale Paeper gpaeper@empirenet.com
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.
-
Gale Paeper -
Paul Isaacs -
Waldek Hebisch