[m-rev.] for review: convert parse trees to strings

[Zoltan Somogyi]

On 2023-11-01 23:00 +11:00 AEDT, "Julien Fischer" <jfischer at opturion.com> wrote:
>> Maybe you would want that, but I wouldn't either want it or not want it.
>> I am afraid such an abstract example cannot convince me either way;
>> I need a real example, preferably with the superclass having more than one
>> subclass, so that I can see the impact of specialization for one subclass
>> on code invoked on values of the other subclass.
> 
> I'm not aware of an example with more than one subclass (there are
> certainly none in the Mercury system).  There are examples within old
> G12 (which is the code base containing the most complex use of type
> classs that I am aware of) where we swap from a subclass constraint to a
> superclass constraint as we descend the call graph.

Yes, I understand that: as you move down the call tree, you
need fewer constraints. Deleting a constraint is one way to do that,
and replacing a subclass with its superclass (or its superclass, etc),
is another.

The problem from my point of view is that if the superclass
has just one subclass, or even just one subclass that is visible
in the module with the pragma, then it is obvious that any
specialization that is done to the predicates which have a constraint
with subclass should also be done to predicates which have a
constraint with the superclass. There is no possible downside,
because that specialization cannot affect any value except
those which are members of the subclass anyway (because
they came from predicates higher up in the call tree which
have the subclass in their constraints). Proper consideration
of the tradeoffs requires evaluating the downside, which
you can't do if there isn't one.

Zoltan.