That is a different issue. It refers to inlining as provided by library(apply_macros). I do agree that macro expansion needs to be better controlled. It is a long debate for which I hoped a standard would emerge around ISO and later Commons and we could wait solving this. I had a discussion yesterday with Teri and David from XSB were we decided to have a closer look whether we can improve on this.
Just a thought, since you mention the standard: what about only expanding apply_macros in static code? As you know, the standard even suggests this (note under 7.5.3):
2 The restriction that only dynamic procedures can be altered enables “partial evaluation” to be performed on any procedure which is static.
That could make sense. It is not clear whether the original poster uses static or dynamic code though. I guess that whether or not library(apply_macros) does its magic should be connected to some optimization flag/option. An alternative would be to make it do its magic only to the modules that include it. Typically one would like to apply such transformations to the whole program or not at all though. The code already says
% @tbd Should we only apply if optimization is enabled (-O)?
You mean, like Logtalk does for more than +20 years with a solution that subsumes what most Prolog systems with a term-expansion mechanism (including SWI-Prolog) do and that can be adapted without breaking backwards compatibility?
The Prolog world is indeed fond of long debates. People love the problems so much that they get quite upset when someone solves them even go as far as creating initiatives like Prolog Commons to keep the Not Invented Here Syndrome ™ alive and well (which, ironically, it was also what doomed the initiative).
Hey! Maybe another “innovation” like “parameterized modules” is in the horizon? That one only took +20 years to be reinvented in partial form so… there’s hope for the next decades!
1 Like
Yes, slowly Prolog will re-invent Logtalk 
1 Like
I just got bit by quintus:log/2 being autoloaded. (I intended to use my log/3 predicate and forgot the 3rd argument.)
As to getting a cup of coffee while things load … I timed loading the entire SWI-Prolog library 83K lines; 2.7MB) and it took 2.2 seconds (i5-7500 CPU @ 3.40GHz × 4 with Samsung SSD). When they were compiled, the time dropped to 1.5 seconds – a 30% improvement. (For a 120K LOC file of facts [25MB], the time drops from 2.7 sec to .15 sec).
Either way, waiting for things to load would be a quick cup of coffee. So, I’m trying to understand the need for lazy loading.
2 Likes
The Logtalk linter would most likely detect and reported that. In its latest versions, it would print a missing use_module/2 directive warning for the quintus:log/2 predicate.
Just read the numbers. Some people use Prolog for relatively small jobs in scripts and startup times matters to them. Over the years startup times tended to get longer, which started to worry me. Other people develop really large applications and shorter startup times makes the development process nicer.
The cost is low. The change to the system is pretty minimal. The system will (eventually) throughout use autoload/2 that allows switching the autoload flags to different values meaningfully. Note that adding exhaustive autoload/2 directives is exactly the same job as adding exhaustive use_module/2 directives and that is most of the work. Not much work for a file, but there are a lot of files and the script only does a 99% job.
Users are free to choose between full autoloading, controlled autoloading or no autoloading, so everybody should be happy. That is what we are after 
1 Like