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

Volker Wysk post at volker-wysk.de
Mon Jan 24 18:27:24 AEDT 2022


Am Montag, dem 24.01.2022 um 17:35 +1100 schrieb Peter Wang:
> On Fri, 21 Jan 2022 20:17:36 +0100 Volker Wysk <post at volker-wysk.de> wrote:
> > > This works for assoc_list because the type definition is exported from
> > > the module. It won't work for types like types like map where the type
> > > is deliberately kept private.
> > 
> > I see. But it would work for assoc_list. Perhaps change the modes of the
> > predicates and functions in question?
> 
> 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.

Something different. Just an idea: If abstract insts were supported (like
abstract types), then maybe it could work the same way as in assoc_list. You
could do such:

:- type map(_K, _V).
:- inst map(_K, _V).

:- pred search(map(K, V)::in(map(K,V)), K::in, V::out(V)) is semidet.


Cheers, Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mercurylang.org/archives/users/attachments/20220124/3df17454/attachment.sig>


More information about the users mailing list