On 2006-03-27, Dylan Thurston <[EMAIL PROTECTED]> wrote: > > --===============0906829955== > Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" > Content-Disposition: inline > > > --3V7upXqbjpZ4EhLz > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Mon, Mar 27, 2006 at 05:02:20AM -0800, John Meacham wrote: >> well, in interfaces you are going to end up with some specific class or >> another concretely mentioned in your type signatures, which means you >> can't interact with code that only knows about the alternate class. like >>=20 >> genericLength :: Integral a =3D> [b] -> a >>=20 >> if you have a different 'Integral' you can't call genericLength with it, >> or anything built up on genericLength. basically there would be no way >> for 'new' and 'old' polymorphic code to interact.=20 > > I think the idea would be that the source for genericLength would > compile using either class hierarchy with no change. For the case of > genericLength, this is true for the proposed alternate prelude Hennig > Theilemann pointed to. It would be mostly true in general for that > proposal, with the exception that you would sometimes need to add Show > or Eq instances.
Right. >> the inability to evolve the class hierarchy is a serious issue, enough >> that it very well could be impractical for haskell' unless something >> like class aliases were widely adopted. > > I think that as long as you're not defining classes source compatibility > would not be hard. Of course you couldn't hope to link code written > with one hierarchy against another. Wouldn't instance declaration also be problematic? (And yes, we desperately need something like class aliases.) -- Aaron Denney -><- _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
