Problems with ISO modules

ISO modules names are constituted only as an atom. In addition there is no real nesting of modules, you just get nesting of module loading because use_module can take some additional information for the load path.

This was probably sufficient for individual software projects, but is rather awkward when you go to having a software development ecosystem in which you imagine thousands of packs, all of which might need modules of their own. The module name “utils” is probably going to be used very often for instance, and which one you get when you try to access predicates is going to be an accident of the order of your load path.

In order to avoid this situation, would it not be better if modules were nested paths?

For instance, a top level module named foo might have a submodule named bar which would keep others from collision.

Has anything like this been implemented before? I imagine this will yield a number of problems with the processing of module stripping etc. Any killer problems?

There is also the problem of violating the ISO standard, but frankly at this point I think it’s time to move on and vendors and distributions can update things if packs in the community turn out to use non-ISO things that people need.

1 Like

Luckily the modules are not ISO :slight_smile: Yes, modules call util.pl are famous :frowning: Some solution to this is surely welcome. Unless there is a good reason otherwise I’d first consider some syntax that ultimately just produces an atom that encodes the hierarchy using name mangling. Might get hard. I wonder whether someone has ever considered this for Prolog …

The common solution is to just invent some short prefix for your project and call all modules e.g. tdb_utils, etc.

3 Likes

That seems like a very sensible way out… I’ll play around with it a bit and see what happens.