coming 2 terms with term_expansion/2

[jjtolton]

I was reading @hurufu's post on term_expansion, and after some digging, it appears that term_expansion is not actually (explicitly) defined anywhere! @mthom mentions expand_term/2 and expand_goal/3 as the public API but they are not documented either 😅

But all the cool kids are defining user:term_expansion/2, so I want to know what it is too!!

[triska]

What do you mean with "not defined anywhere"? The link in your post shows several examples of modules that do define term_expansion/2. term_expansion/2 is automatically invoked for every Prolog term that is read when consulting a file, with that term as the first argument. If the call succeeds, then the term indicated by the second argument is compiled instead of the original term, otherwise the original term is compiled.

[triska]

Also, if I was supposed to know this somehow, I'd love to know how I was supposed to know so I can go and read whatever that thing is so I can be less ignorant

Nobody knows how this is all supposed to work, please see for example #2532. Thanks to the questions you filed, I now looked at loader.pl and noticed that module-specific term_expansion/2 definitions may unexpectedly affect code outside of their module, I have filed #2608 for this, thank you a lot!

[jjtolton]

Ahhhh there it is!!! I completely missed that there were more search results, great catch.

There are a few other things that use this "hook"-like techique, for instance, with attribute_goals//:

and with verify_attributes//:

And the reason why I'm asking is I'm wondering if this collection of hook-like predicates would constitute some sort of compositional "pattern", and I'm wondering if it is a good candidate as a larger compositional pattern as we are discussing.

So for instance:

Here I have made (adapted) a generic A* module. The only thing a client implementation needs to do is define an s/3 successor predicate and an h/2 heuristic predicate (as I did with eight puzzle) -- this seems very much like the technique used with term_expansion/2, verify_attributes//, etc. Yes, the control flow is not exactly the same, but the "API" has a similar "feel".

So this would allow you to define a different "submodule" for each domain specific problem while reusing the generic A* module.

As such it would seem like this is a candidate for a good compositional pattern. However, I have my hesitations. verify_attributes// and attribute_goals// seem to have access to submodule information, and they seem to be special in that regard. I have not found any easy way to write a generic predicate that can be invoked by a client module which can access the client module information. That may be a good thing or a bad thing, but it is a thing.

Just more questions in my quest to understand how to write extensible Prolog!

[jjtolton]

No, I'm thinking "hooks" like this are not a very good idea, now that we've dug in somewhat. It makes
more sense to write generic predicates as meta predicates that use call/N to achieve inversion of control rather than implicit hooks. I forgot we could use call/N to do that 😰.

[hurufu]

It is useful to think about foo:bar. not as a namespace, but as invoking predicate bar/0 in the context of module foo. For example you can have code like this lists:call((X=1, length(A, X))), write(A) this will work even if you don't have length/2 imported.

[hurufu]

Basically you can call any predicate in the context of any module.