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

[Ace]

Just my 2c:

I would be very interested in seeing an alternative standard lib written in
this style, similar to how Haskell has multiple alternative Preludes:
https://guide.aelve.com/haskell/alternative-preludes-zr69k1hc

That way the full implications can be tested, and code available to anyone
who wants to use it, before upstream commits one way or the other.

Aistis Raulinaitis

On Wed, Jan 26, 2022 at 1:03 PM Dirk Ziegemeyer <dirk at ziegemeyer.de> wrote:

>
> > 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.
> _______________________________________________
> users mailing list
> users at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20220126/de33e1c7/attachment-0001.html>