[m-rev.] for review: convert parse trees to strings
Julien Fischer
jfischer at opturion.com
Wed Nov 1 21:42:16 AEDT 2023
On Wed, 1 Nov 2023, Zoltan Somogyi wrote:
>
> On 2023-11-01 16:08 +11:00 AEDT, "Julien Fischer" <jfischer at opturion.com> wrote:
>>
>> On Tue, 31 Oct 2023, Zoltan Somogyi wrote:
>>
>>> The diff adds the typeclass constraint "pt_output(S, U)"
>>> to many predicates in the compiler. To avoid losing efficiency,
>>> we want to created versions of those predicates specialized
>>> to their current use case (where S is an output stream,
>>> and U is the I/O state), and their intended new use case
>>> (where U is string.builder.state, and S is the corresponding handle).
>>>> Unfortunately, adding two type_spec pragmas to every predicate
>>> with that constraint has two problems. First, it is tedious, and
>>> second, if any predicate is missed either now or later as new
>>> predicates are added, we lose the benefit of specialization
>>> in the affected part of the call tree. (This is already an issue
>>> in files such as library/term_io.m.)
>>
>> This kind of what we might call templatey specialisation is an issue
>> beyond the compiler, see for example my mercury_json library.
>
> Yes, I knew that. It is an issue already in e.g. library/term_io.m.
Such a pragma may also be an opportunity to get rid of the special
casing that occurs in stream.string_writer.m.
Julien.
More information about the reviews
mailing list