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

[Zoltan Somogyi]

On 2023-11-01 21:41 +11:00 AEDT, "Julien Fischer" <jfischer at opturion.com> wrote:
>>> 3. Some of the constraint arguments are ground.
>>
>> Your example exihibits 1 and 2, but not 3. What do you propose to do
>> about/with ground args?
> 
> Good point, I suppose in that case you would only want the pragma
> to match the constraints that have the ground arg.  So my example
> below, should really look like:
> 
>    :- pragma type_spec_constrained_preds(
>         [line_oriented(Stream, State),
>          unboxed_reader(Stream, char, State, Error)
>          putback(Stream, char, State, Error)],
>         [Stream = io.text_output_stream,
>          State = io.state, Error = io.error]).
> 
> And we would only specialise predicates whose constraints had
> unboxed_readers and putback streams with their Unit set to ground.

That makes sense.

>> 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?
 
>> 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.

Zoltan.