[m-dev.] foreign_import_module

[Julien Fischer]

Hi Zoltan,

On Wed, 19 Jun 2019, Zoltan Somogyi wrote:

> Attached is a proposed diff of the documentation of foreign_import_module,
> for review by anyone. I would particularly like to know if anyone knows the answer
> to the question in the XXX it adds.
>
> The reason I am posting this to mdev and not mrev is because I recently realized
> that some of the difficulty I had working on foreign_import_module items (FIMs for short)
> was caused by their misleading name. It *sounds* like it is a foreign language
> version of the :- import_module declaration, but it is quite significantly different.
> A FIM item says nothing about what .h file (or non-C equivalent) *this* module needs
> during its compilation; it talks about what .h files *other* modules importing this one need
> when *they* are compiled. Since we could call these other modules "client" modules,

That isn't my understanding of the situation.  If module A has a
foreign_import_module declaration that imports module B, then that is
module A saying that code in its foreign_* pragmas refers to things
declared in the (applicable) foreign_* pragmas of module B.  In C grades
this achieved by generating code in module A that #includes the .mh file
for module B.  Furthermore, the foreign_import_module pragma tells the
build system that this dependency on B's .mh file exists.  You can
foreign_import a module with having normal :- import_module declaration
(e.g. where only the foreign code of the importing module uses stuff
from the imported module).

Originally, this behaviour was supposed to extend to a module itself,
but it appears that I changed that in commit 9482049.  (It's a long time
ago but IIRC the difference in behaviour between the two C backends was
causing a good deal of grief at the time.)

> I propose that we rename foreign_import_module to something like
> foreign_import_for_client_modules. We would of course continue to accept FIM
> syntax as well, for a long while.
>
> What do people think? Do people agree that a less misleading name would help,
> and does anyone have a better and/or shorter name than foreign_import_for_client_modules?
>
> In the longer term, I am also planning to delete foreign_import_module items from
> item blocks altogether, replacing them with a set of "module_name, foreign_language" pairs
> at the top level of module parse trees, in part to avoid having to worry about duplicate FIM items.
> Any objections?

To that last part, no.

Julien.