Tracking how/why a term is ground

The simplified version of my requirement, is:
If I have A = [X,Y] and later I establish ground(A), what is the best way to track if ground(A) is because A was unified directly, or because X and Y were unified?

When I say “the best way”, I’m just looking for idiomatic/performant Prolog. And I’m asking because starting with A = [X,Y] in Prolog, one is typically suggesting that they care about the relationship but NOT the mechanics by which it was resolved in a particular case. So I feel like I’m somehow going against the spirit of Prolog here.

Making A ground would be the same thing as making X and Y ground (in any order).

Seems like an unusual request. What are you really trying to do? There may be a better way than checking ground/1 at various points in the code.

Why not replace A with [X, Y] in the code? Can’t have variable A causing confusion, if it doesn’t exist :wink:

What I want, (for visualization purposes) is to display the deepest lists differently if they were “solved/set/unified directly “ vs having each member unified.

I can replace the list with some other structure that would track this, or I can maintain a list of solving steps and revisit it after the fact. Though it won’t always be needed and I want the ability to avoid the overhead.

Does “having each member unified” mean that the list elements are made ground in order? If that is a safe assumption in your code (along with such a thing not being possible in the alternate path), then could use when/2 to check (e.g. that the first element became ground before the second element did).

1 Like

For my case, it turns out I can just do my solving in a transaction, track which lists are unified in one shot with asserts, render my visualization in the transaction where I have access to that knowledge, and toss those details when the transaction ends. It works out very cleanly.

It sounds like you want to override the default behaviour of =/2 . I can only think of meta-interpreters to help you with that. Otherwise, you should take a step back and focus on the “real” problem like brebs said.

1 Like

Great link! Thank you!