[m-rev.] for tryout: type_spec_constrained_preds

[Julien Fischer]

Hi Zoltan,

On Fri, 2 Feb 2024, Zoltan Somogyi wrote:

>
> On 2024-02-02 01:49 +11:00 AEDT, "Julien Fischer" <jfischer at opturion.com> wrote:
>> For (1) we can add the following pragma:
>>
>> :- pragma type_spec_constrained_preds(
>>         [stream.line_oriented(Stream, State),
>>             stream.unboxed_reader(Stream, char, State, Error),
>>             stream.putback(Stream, char, State, Error)],
>>         apply_to_superclasses,
>>         [
>>             subst([Stream = string_reader,
>>             State = string_reader_state,
>>             Error = string_reader_error])]).
>>
>> That compiles successfully at the standard optimisation level;
>
> That itself seems to me to be a problem. The reason why I think that
> is that I manually added a type_spec pragma with the above substitution
> for the three predicates listed in the error message for the intermodule case:
> make_error_context, make_syntax_error, and make_unexpected_eof_error.
> It worked for the last two, but gave an error for the first. That error is
> that make_error_context does not have a type var named Error occurring
> in the types of its args, BUT it does have a type var named Error occurring
> in its typeclass constraints. The fourth sentence of section 11.5 of the reference
> manual (rotd version) says that this should not happen, but it seems the compiler
> does not check compliance with this rule *unless* you happen to have a type_spec
> pragma for the predicate :-(

The fifth sentence of section 11.5 says that such variables *are*
allowed if functional dependencies are present and the variable's type
can be determined from other variables. In the case of the
unboxed_reader type class, the functional dependency
(Stream, Unit -> Error) is present.

> That seems to me a preexisting bug, but probably not the kind that you were
> expecting.

Certainly one "bug" there is that the unboxed_reader constraint is
redundant on all three of those predicates.

...

>> In the cases that succeed, the specialisations I would expect are
>> present in the generated C code, although I have not looked at how
>> effective they are.
>
> The diff I committed earlier today should help with that.
>
> I am attaching the three files that I have modified as part of the fixes
> described above. If you apply them to the earlier version, you should get
> my current version. Can you please check whether there are any remaining
> problems, either with csv or json?

I have updated my compiler with the latest modifications and both
libraries now compile succesfully (at --intermod-opt -O5).
(Note that I have updated the json library so that the fourth
specialisation I mentioned is actually relevant.)

Julien.