I assume you are considering that a similar effect can be accomplished using:
p(L) :- L = [H|T], ..., q(L).
I assume you are considering that a similar effect can be accomplished using:
p(L) :- L = [H|T], ..., q(L).
As a general observation, abnormal cases where an optimization technique introduces an overhead can be found in most programming languages. In the particular case of the Logtalk transformation, it only applies when compiling in optimized mode and can be easily bypassed (by e.g. bypassing the unification goals using the {}/1
control construct).
An interesting question is if folding of left unifications should be restricted to only those introduced when compiling grammar rules. This would leave unchanged any cases of explicit sharing wrote by the programmer. But I have seen several times programmers writing clauses like:
p(X, ...) :- X = ..., % big term
simply to keep head clauses short. In these cases, the optimization is likely welcome. I think this issue is clearly worth a note in the documentation of an optimizer but itβs not clear if the behavior of an optimizer doing folding of left unifications should be modified.
Surely you can achieve that after source transformation. A brief investigation shows that indexing the above for the default first argument indexing which is used for predicates with not many clauses and called with an instantiated first argument is probably not too hard.