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

[Julien Fischer]

On Wed, 1 Nov 2023, Zoltan Somogyi wrote:

> On 2023-11-01 21:41 +11:00 AEDT, "Julien Fischer" <jfischer at opturion.com> wrote:

>>> But what should happen for predicates whose typeclass constraints specify
>>>
>>> - a nonempty but strict subset of the constraints in the first arg, and/or
>>
>> For code that I have written or worked on: constraints are dropped as
>> you move down the call graph. To take the JSON library, for example, at
>> the top-level we have the three constraints above; at the leaves of the
>> call graph there is usually only a single constraint,
>> unboxed_reader(Stream, char, State, Error).
>
> And so does this. So I presume you would want the pragma to apply
> to any pred/func whose set of type constraints has a nonempty intersection
> with the set of type constraints in the pragma, as long as ...
>
>> (Obviously, this could be avoided by having potentially redundant
>> constraints all the way down, but that seems undesirable.)
>>
>>> - the variable sharing arrangement that is different than in the first arg?
>>
>> I think if the variable sharing arrangement is different, then there
>> should not be match.
>
> ... this constraint is satisfied. Would that be a correct interpretation
> of what you are saying?

Yes.

>>> With my original proposal, which included only a single typeclass
>>> constraint, the answer was fairly obvious: you apply to a pred or func
>>> all of the type specializations mentioned in the pragmas that apply to it,
>>
>> Actually, I don't think the single typeclass constraint case is as obvious
>> as you think due to the presence of superclasses.
>
> You raise a good point.
>
>> Consider:
>>
>>    :- typeclass class1(T) where ...
>>
>>    :- typeclass class2(T) <= class1(T) where ...
>>
>>    :- pred foo(T, ...) <= class2(T)
>>
>>     foo(...) :-
>>       bar(...).
>>
>>    :- pred bar(T, ...) <= class1(T).
>>
>> In presence of
>>
>>    :- pragma type_spec_constrained_preds(class2(T), [T = int]).
>>
>> you would want the specialization to also apply to the predicate bar.
>
> 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. From the quick look
I just had, I'm not sure it's necessary in many of those cases and I
suspect many of them arose as a result of code being moved from
elsewhere. (It's a moot point, since the optimisation we are discussing
in this thread would not apply in G12 anyway.)

Julien.