Term and goal expansion

See https://logtalk3.readthedocs.io/en/latest/userman/expansion.html for a summary of Logtalk’s term-expansion mechanism. Happy to discuss and provide feedback.

P.S. The ReadTheDocs website is used just for previewing the git version of the Handbook. Some links may not work as only the git version of the Handbook is published there. In alternative open the manuals/index.html file in the git version after a git pull.

I moved this to a new topic. It is only very indirectly related to autoloading. I’ve just completed reading through the approach in

  • Logtalk
  • SICStus
  • ECLiSPe
  • Ciao
  • XSB
  • [SWI-Prolog] (I know without reading :slight_smile: )

I’ve working on some comparison charts which are not yet in a state ready for sharing. The differences and common aspects are rather interesting though. Did I miss interesting systems that do it yet in another way? Or possibly I missed an analysis with the same purpose already assembled by someone else?

So far I think it is possible to come up with something that combines the good stuff and, not unimportant, can provide near or complete compatibility with the current SWI-Prolog approach. This has, as you have stated many times, severe flaws, but also some good points as well.

Adopting the Logtalk solution, only with hook modules instead of hook objects, would require:

  1. A hook/1 option for load_files/2.
  2. A hook Prolog flag.

For backwards compatibility, the default value of the hook flag would be set to user. When compiling a source file, the priority would be:

  1. The hook module as declared by a set_prolog_flag/2 in the file itself if any.
  2. The hook module declared in the load_files/2 option if any.
  3. The default hook object.

Sorry for the self reply and the relatively long term passed since the previous post in this thread.

l published today a blog post on term-expansion that you may find relevant:
https://logtalk.org/2020/03/24/a-dependable-term-expansion-mechanism.html

1 Like