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

[Julien Fischer]

On Wed, 1 Nov 2023, Zoltan Somogyi wrote:

> On 2023-11-01 16:08 +11:00 AEDT, "Julien Fischer" <jfischer at opturion.com> wrote:
>>> The internal representation of this pragma would record the name
>>> of the module in which the pragma appears. (This would happen regardless
>>> of whether it appears in a .m or in a .intN file.) The compiler would
>>> then apply the type specialization described by the second arg
>>> to all predicates and functions in that module that have the
>>> type constraint in the first arg.
>>
>> So it only applies to a single module?
>
> What is your alternative?

What prompted my question was the arrangement I have in mercury_json,
where most of the work is subcontracted to (private) submodules.  That's
not uncommon -- the examples in the compiler and term_io are just not
large enough to warrent it. My suggestion would be that at minimum, the
optimisation should apply to a module plus its child modules.

> I guess we *could* specify that if this pragma occurs in a module
> that defines and exports
>
> - a type class and
> - an instance of that type class
>
> then if it also has this pragma in its interface for that pair, then all modules
> importing that module automatically get its effects. However,
> we already have modules in the compiler for which we explicitly
> disable some optimizations in Mercury.options, because the
> optimization applies only to rarely executed code, and the cost
> in extra code size is too much to pay for any speedup the
> optimization may bring.
>
> So yes, I think the scope of the pragma should be the preds/funcs
> in the module in which the pragma appears. This gets the vast majority
> of the benefits with minimal cost in typing, and avoids the need
> for any extra mechanism to address the above issue.
>
> My guess is that you are concerned about type specialized code
> in one module calling a could-be-specialized-but-isnt predicate
> in another module. We could address that concern by adding
> either a warning or an informational message when that occurs.
> This message could operate regardless of whether the type
> specialized predicate was specialized by an old style pragma,
> or the new form.

That's a good idea; as I mentioned above, my main concern is with
how the pragma applies to submodules.

>>> We *could* deprecate and eventually stop supporting the old syntax,
>>
>> We should deprecate and eventually stop supporting it.  (But it doesn't
>> have to be soon.)
>>
>>> but I don' see much to be gained by that course of action.
>>
>> - not having to maintain the code that supports to the old syntax.
>> - potentially not confusing users, by having two syntaxes.
>
> The old code we would have to maintain is tiny, and needs no real maintenance
> anyway, which is why I wrote what I wrote. About user confusion: disabling
> the old syntax will probably increase confusion during the changeover,
> but reduce it in the long run, so you are right, we should eventually stop
> supporting it. We could deprecate this syntax in the next release, with
> a warning that can be disabled with --no-warn-obsolete, and then remove
> support in the release after that. How does that sound?

That's fine.

> Does anyone object to me committing this diff without this new pragma
> in place? I would prefer to do so, to reduce the risk of conflicts, accepting
> the temporary perf penalty.

No, go ahead and commit.

Julien.