-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/05/13 15:00, harry wrote:
Brent Yorgey
writes: On the other hand, if you sincerely want to know why, it is simply that this kind of feature does not fit nicely within the space of the design decisions that were made when creating Haskell, for example: (1) All the elements of a list must have the same type. (2) A type class cannot be used as a type. (3) Haskell has no subtyping. And there are good reasons behind these decisions as well. For example, subtyping makes type inference nigh impossible.
Yes, (2) is what I don't understand. I recently ran into this with a GUI application, where I needed to process a list of widgets that were members of the same typeclass, but I had to wrap them all because they were different types.
So so rephrase my question, why can't type classes be used as a type? Is this an implementation issues, or is there a semantic problem with this? Type classes can't be used as types because they are not types. It's just that simple. To achieve what you want you actually create a new type (with `data') and put a type class constraint on the types it accepts. We can then use that type for our collection.
Creating an existential type and packing all the values seems like busy work which shouldn't be necessary, or at least something that the compiler should be doing for me. Yes, it is in fact busy work and yes, it could probably be done for you by the compiler. I imagine the reason it isn't is simply because forcing heterogeneous collections where only homogeneous ones were intended is usually a sign of the fact that you are doing it wrong and usually there's a better solution. Putting in direct support for it in the compiler would just make the compiler more complex and effectively encourage bad programming. It's just not something that comes up often enough to warrant a compiler extension.
- -- Mateusz K. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRpL8cAAoJEM1mucMq2pqXFiMP/jaK3i6sW+R7aoKqp3UwjgRM SSdD1zEpcPtMRwoucpW0GDk+gjtIvqTcrpo5THD6w59G1Pwvm/8G+852xHfdPVUs NmpYtz1an4mGeJZmz7One0UbX+Bh7mz83E/fLkUJ4FrBXF7q9XFVPwhkRb+5F4Yd BovYSPwmGsUslXc785UE2J3G/nPW61jtw+w0k+SRuD7wJd/0JQO54rp3PQt5udO+ GF022pOqB+IWxIAqaZ+CEPiEotrGLe6tJzvE8J0vgkcgTpGrumRyJRz/yRc0foXi FuOgRPr1dgaajanMOcaapWkf0aE1RxfIR0iDWgcQZYpPlU6nTz9XhQZ0216udUHr px5PnpFSFmVHdtWxdMEjY5zBlV51TwUZm01kQQ+mBO4cqsHJNEuSFSpcOoMddH/X P/s/dTUtWp01cjSCkxahDCltvuDNmmOGT5kfmZ22YdOGTdbsjCVY/tHM6WFDb8OB 6j2a8YovorskWx5Mpw+3GS5VOn7KgDvKXoRvCQL8KvRLBlekVGHjXRz9kQRTGQwW KV9WcNQU46mw1tyLJaD5zbKko8HvGUc4I8DdbtMLnJ3KQuiTQIp677QyoGFZcE1C USyvG3E+lsXU9fBw3GpxPfSQLM0t3waL4tMdKXt0urIidSJdpIPNJrS+SICxF62Z FpJ3V8/U7lnjo0z6/Iy0 =yKxA -----END PGP SIGNATURE-----