Been there Jan at the time also didn’t want those changes for the reasons he explained in his reply.
Personally, I strongly dislike the autoloading mechanism and the single reason I don’t turn it off is that SWI-Prolog doesn’t even start without it enabled. Try e.g.
$ swipl -g "set_prolog_flag(autoload, false)"
Why the dislike? Although the autoloading mechanism saves typing and makes the source code a bit smaller, it strongly reinforces the idea of a single namespace for all predicates, independently of those predicates being encapsulated in modules. In fact and in practice, it imposes that idea. It works with the semantics of the
use_module/1 directive. But this directive is flawed in that a simply addition of a new predicate to a module, that an existing application necessarily don’t use, can break the application.
These potential issues are avoided by programmers attempting to ensure that their exported predicates don’t clash with the exported predicates of other modules. This is inherently non-scalable. It also forces programmers to come out with alternative names instead of using the best possible names. E.g. the
lists module has the exclusive of the
member/2 predicate name. Everyone else, back off. Or complain loudly that an existing library module exports a predicate that a new library should have the right of use. That happens. E.g. it’s why
ugraphs:transpose_ugraph/2 so that we could have
It also results in programmers, newbies and not so newbies, having no idea of the dependencies of their applications (despite of the availability of tools, as Jan remarked, that can list those dependencies; but tools are only useful when programmers use them…). They often have no idea if they are using a built-in predicate, a library predicate, a deprecated predicate, a core library predicate, a third-party predicate, a foreign predicate (that may not behave and even be available on a different operating-system), …
Again, tools and documentation are available but are also too frequently ignored. More conscious programmers will of course use them. Still, as good as tools and documentation may be, the practical consequence is that of a single predicate namespace. To be fair, the root of these issues is actually the module system. But the autoloading mechanism strongly reinforces those negative traits.
Admittedly, these issues are more of a concern in large applications (and by large I mean applications where a single person would have trouble, if able at all, to keep all details in his/her head to avoid these issues). But that only leads to question the validity of mechanisms presented as solutions for programming in the large in the first place.
P.S. Take this post as reflection points, not as an attack on SWI-Prolog design choices.