[m-rev.] for review: string.builder.append

[Julien Fischer]

On Thu, 15 Feb 2024, Zoltan Somogyi wrote:

> For review by anyone. Since I intend to work on this later today,
> I would appreciate either a quick review, or an instant review/approval
> of the concept and a promise of a post-commit review.
>
> In a separate diff, I intend to move the code affected by this diff
> in get_dependencies.m to format_call.m, for easier future maintenance.
>
> The motivation for this diff is that I want to arrange for .*opt files
> to be compared to their earlier versions the same way we now do this
> for .intN files: by reading in the old file as a string, and comparing it
> to the string form of the new version. This obviously requires the string
> form of the new version, but currently we can't construct that, because
>
> - a significant part of .opt files consists of clauses,
> - intermod.m uses write_clause to write those clauses,
> - write_clause has no clause_to_string version.
>
> I could generalize write_clause by using the string.writer interface
> to *either* build up a string *or* do I/O directly, but after the change above,
> I don't think we will ever need the latter, because all our use cases,
> both in normal operation and when debugging the compiler,
> will prefer the former.
>
> I therefore intend to change hlds_out_*.m, almost all of which now
> just does I/O, to use string.builders everywhere, and to do so directly,
> without going through the string.writer interface.
>
> Are there any objections?

Not from me.

> Add string.builder.format.
> 
> library/string.builder.m:
>     Add the predicate string.builder.format. We already have
>     string.writer.format, one of whose instances, the one for
>     string.builder.{handle,state}, does a string.format and adds
>     the resulting string to the given string builder. The new predicate
>     allows this to be done directly, without the type class overhead
>     (both conceptual overhead, and compilation time overhead) in cases
>     where the generality of type class is not needed.

That's fine.

Julien.