[Haskell-cafe] Type vs TypeClass duality

[Sterling Clover]

I'm relatively new to Haskell, so maybe this answer is a bit off, in  
that I'm sure there are times when some sort of auto-existential  
creation may have a point, but generally I've found that when I want  
it I've been thinking about the problem wrong.

The bigger issue is that as soon as you get fancier types classes,  
they'll probably be paramaterized over more than one type, not to  
mention with possible functional dependencies, etc., and very likely  
be polymorphic over return value as well. in fact, I suspect, Show  
and maybe fromIntegral or such aside, cases like you describe where  
you might even have the possibility of doing what you're looking for  
(i.e., a list of a typeclass such that a function in it is guaranteed  
a single return type) look fairly rare.

Integrals are a good example of what I ran into early on -- suppose  
you had a [Integral] rather than one of "Integral a => [a]". What  
would be the advantage of this? It would actually make your code  
messier -- instead of a case of, e.g. [x:x':xs] -> x+x' you wold need  
one of [x:x':xs] -> fromIntegral x + fromIntegral x', otherwise you  
would have no guarantee the types would match! And even then, what  
would the return type of this function be? Polymorphic over Integral?  
You'd just be spreading the fuzziness over type to the rest of your  
program, and probably introducing a load of potential inefficiencies  
to boot.

I suspect that you may still be trying to code with an OO mentality  
which thinks of the methods of a typeclass as "within" it as they are  
within an object, rather than as _on_ it.

--s

On Oct 23, 2007, at 4:09 AM, TJ wrote:

> Hi again,
>
> Following up on my previous thread, I have figured out why it bothered
> me that we cannot have a list such as the following: ["abc", 123, (1,
> 2)] :: Show a => [a]
>
> It seems to me that there is an annoying duality in treating simple
> algebraic data type vs type classes. As it stands, I can only have a
> list where all the elements are of the same basic, ADT, type. There is
> no way to express directly a list where all the elements satisfy a
> given type class constraint.
>
> If I am not mistaken, type classes are currently implemented in GHC  
> like so:
>
> Given a function "show" of type Show a => a -> string, and the
> expression "show 10", GHC will pass the Int dictionary for class
> Show's methods and the integer 10 to the function "show". In other
> words, for each type class constraint in the function type, there will
> be a hidden dictionary parameter managed entirely by the compiler.
>
> What I find strange is, if we can have functions with hidden
> parameters, why can't we have the same for, say, elements of a list?
>
> Suppose that I have a list of type Show a => [a], I imagine that it
> would not be particularly difficult to have GHC insert a hidden item
> along with each value I cons onto the list, in effect making the
> concrete type of the list [(Dictionary Show, a)]. I'm assuming that it
> will not be particularly difficult because GHC will know the types of
> the values I cons onto it, so it will most definitely be able to find
> the Show dictionary implemented by that type, or report a type
> mismatch error. No dynamic type information is necessary.
>
> I am not an OO programming zealot, but I'd like to note here that this
> is also how (class based) OO languages would allow the programmer to
> mix types. e.g. I can have a List<Show> where the elements can be
> instances of Show, or instances of subclasses of Show.
>
> Why does this second rate treatment of type classes exist in Haskell?
>
>
> TJ
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe