[m-users.] Issue with assoc_list and other container types

[Dirk Ziegemeyer]

> Am 24.01.2022 um 07:35 schrieb Peter Wang <novalazy at gmail.com>:
> 
> If I'm remembering correctly, historically there were concerns about the
> performance impact on the compiler if inst parameters or complex insts
> were more widely used. There may have been some concerns about
> correctness as well, I guess. (My view may be coloured by having to fix
> some bugs with constrained polymorphic modes a few years ago.)
> 
> Obviously any problems uncovered would (necessarily) be addressed if we
> started using parameteric modes in the standard library, so it may just
> be a matter of committing to it.

Are there any reasons for not committing to a mode-polymorphic standard library?

I remember these issues when using insts:
1. Mode declarations will become much longer and intimidating.
2. Compiler errors in case of inst mismatch can be very long and hard to read in case of insts with a lot of constructors.

Example of 1)

Now:
:- mode list.foldl4(pred(in, in, out, in, out, in, out, in, out) is det,
    in, in, out, in, out, in, out, in, out) is det.

With mode-polymorphic insts: 
:- mode list.foldl4(
    pred(in(I0), in(I1), out(I1), in(I2), out(I2), in(I3), out(I3), in(I4),
        out(I4)) is det,
    in(list(I0)), in(I1), out(I1), in(I2), out(I2), in(I3), out(I3), in(I4),
    out(I4)) is det.