On Thu, 21 Dec 2023 at 02:13, Gaius Mulley wrote:
I propose implementing <*FFI="C"*> also <*FFIDENT="foobar"*>,
Great!
thanks for the explanations of their rationale
You're welcome. And thanks for your consideration.
Perhaps I should also elaborate a bit more on the approach I advocated for the opposite use case, where a library written in M2 is compiled for use within C code.
As I had mentioned, this use case is merely a compilation for a different target, where the target is not a specific hardware architecture but a C compiler and its runtime environment.
And since it is neither common nor desirable to specify compilation targets within source code when targeting specific hardware platforms, there should not be any need to specify C as a target within the M2 source code either.
Instead, compilation to a given target is generally done by specifying the target as parameters for the compiler, either by command line arguments, or by compiler configuration settings. Therefore, this should also be the case when targeting C.
$ m2c foolib.mod --target=C
This means that there should be no need to specify neither the target nor any naming conventions within the Modula-2 source code.
Thus NO syntax like 'FOR "C"', NO pragma like '<*FFI="C"*>' and the like.
Instead, the compiler switch tells the compiler that C is the target.
Also, NO syntax like 'EXPORT UNQUALIFIED' NOR any pragma to this end.
Instead, if C has been specified as target, names are automatically exported unqualified, thus without name mangling, at least by default.
If it is desired that the module name is prefixed to all exported names and have to be used in that way from the C code that will use the M2 library, then this should be specified by another compiler switch and/or configuration setting.
$ m2c foolib.mod --target=C --ident-xlat=snake-case --ident-prefix=module-id
It should then be up to the compiler to translate Modula-2 identifiers to C identifiers accordingly. For this purpose, the compiler needs to implement a name translation scheme and this needs to be properly documented.
I designed and specified one such name translation scheme from Modula-2 to C. Gaius, if you want to implement such a feature in gm2, feel free to use it.
It is possible to design, specify and implement multiple such translation schemes for different target naming conventions, but of course this adds time and effort, so one should be careful not to get carried away by ambition. ;-)
The benefit of automatic identifier translation is that it is the most user friendly, from the viewpoint of the author and maintainers of the Modula-2 source code. The source code can be written without having to worry about target naming. Furthermore, the same source code can just be compiled for other targets without modification.
The downside of automatic identifier translation is that there will always be some odd cases where a target name is desirable which doesn't follow the translation rules. But this is not a justification to put the desired names into the source code.
If custom name specification is desired, it should be specified outside of the source code. Since it is not really practical to specify custom name translations as command line arguments, they should be specified in a configuration (or name translation) file.
Custom names will most likely be used by multiple libraries anyway, so it makes sense to edit a simple dictionary for the translations from M2 to C.
$ cat ciolib-xlat.dict
PrintF=printf;
ScanF=scanf;
...
Such a dictionary file can then be specified as a command line argument
$ m2c CIOlib.mod --target=C --ident-xlat=snake-case --ident-prefix=module-id
--custom-xlat=ciolib-xlat.dict
Custom name translations in the dictionary would then override automatic translations.
This is the most user friendly approach, both for the author/s and maintainer/s of the Modula-2 source code, but also for the C users of the resulting library.
At the same time, it leaves the source code completely unmodified, following the philosophy that how code is compiled is a compilation specific detail and ought to be done via compiler switches/settings/configuration.
hth
regards
benjamin