[Haskell-cafe] Re: Positive integers

[Aaron Denney]

On 2006-03-27, Dylan Thurston <dthurston at barnard.edu> 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
-><-