Sat, 24 Jun 2000 13:10:24 -0400 (EDT), Chris Okasaki <[EMAIL PROTECTED]> pisze:
> I considered this for Edison but rejected in for two reasons.
> First, it constrains the implementation, adding an extra level
> of indirection to every access.
It does not, if extra functions for association maps are methods
themselves, instead of always going through generic functions on
(:=) pairs.
This means that collections would still need to get some trivial
instances to be used as maps.
> Second, and more seriously, it moves the unconstrained type variable
> into the class, which leads to several potential problems such as
> more ambiguity messages.
Indeed. I'm not sure know how big the problem is...
OTOH I can imagine types that need these constraints: sequences of
bits, packed strings of characters, containers shared with foreign
languages. IArray does constrain elements and has unboxed arrays
as instances.
It seems impossible to unify things that currently share names, without
either constraints on elements or contexts with local foralls :-(
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-
