[m-rev.] for post-commit review: simplify maybe_written_specs

[Julien Fischer]

On Wed, 29 Apr 2026 at 17:26, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:

> Simplify maybe_written_specs.
>
> compiler/error_util.m:
>     Replace wrappers around individual error_specs with simply using
>     two lists of error_specs.
>
>     Define some needed operations on the new type.
>
> compiler/write_error_spec.m:
>     Simplify the affected code.
>
>
> diff --git a/compiler/error_util.m b/compiler/error_util.m
> index 4eb4177ee..9accaa985 100644
> --- a/compiler/error_util.m
> +++ b/compiler/error_util.m
> @@ -93,36 +93,31 @@
>
>  %---------------------------------------------------------------------------%
>
> -:- type maybe_written_spec
> -    --->    to_be_written_spec(error_spec)
> -    ;       already_written_spec(std_error_spec).
> -            % Sometimes we want to both
> -            %
> -            % - print an error_spec just after it is generated, and
> -            % - also return it to inform decisions about the presence
> -            %   of errors.
> -            %
> -            % To prevent the caller from writing out a duplicate copy
> -            % of the error_spec, we can return it wrapped up
> -            % in this function symbol, which
> -            %
> -            % - preserves its severity (for decisions),
> -            % - preserves its text (which may be helpful when debugging
> -            %   the code that makes those decision),
> -            % - but which write_error_spec.m knows to ignore.
> -            %
> -            % An alternative design would create a new type, called maybe
> -            % gen_error_spec, which contains error_spec's three function
> -            % symbols *and* already_printed_spec, and make error_spec
> -            % a subtype of this new type. This design works (I, zs, have
> -            % tested it), but it makes references to error_spec's three
> -            % function symbols ambiguous, since their type can be either
> -            % error_spec or gen_error_spec. In most cases, the surrounding
> -            % context resolves the ambiguity, but in some cases, it does not.
> +    % Sometimes we want to both
> +    %
> +    % - print an error_spec just after it is generated, and
> +    % - also return it to inform decisions about the presence of errors.
> +    %
> +    % To prevent the caller from writing out a duplicate copy of an
> +    % error_spec, we can move it to the already_written field. This
> +    %
> +    % - preserves its severity (for decisions),
> +    % - preserves its text (which may be helpful when debugging
> +    %   the code that makes those decision),

s/decision/decisions/

> +    % - but which write_error_spec.m knows to ignore.
> +    %
> +:- type maybe_written_specs
> +    --->    maybe_written_specs(
> +                to_be_written       :: list(error_spec),
> +                already_written     :: list(error_spec)
> +            ).

That's fine otherwise.

Julien.