Re: [Haskell-cafe] I hate Haskell's typeclasses

23 Apr 2008


      On 22 Apr 2008, at 9:53 AM, Ryan Ingram wrote:
...
On Mon, Apr 21, 2008 at 10:58 PM, Jonathan Cast
 wrote:
...
I must have failed to communicate well.  To me, the point of  
giving a class
a name is that then you can write a program that is parametric  
over the
elements of that class.  Knowing that I can implement monads in  
Ruby doesn't
impress me nearly as much as knowing that I can implement mapM does.
Haskell has me addicted to code reuse (mapM) the way the rest of the
programming world is addicted to design patterns (monads).  What I  
mean by
`encoding Num and Monad' is that you can do something like this:
sum = foldr (+) 0
 sequence = foldr (liftM2 (:)) (return [])
I don't know of any language that is dynamically typed and also  
can encode
`return' or `0' in a way that lets those examples work.   
Statically typed
languages where it works are rare, even.  Haskell gives up a fair  
amount of
control by making these things implicit, which is what I think you're
running up against --- but I think it gets something useful and  
non-trivial
to acheive in return.
I think ruby generally solves this problem via duck-typing; instead of
the cast happening in the (implicit) fromInteger call in sum above,
instead the cast happens in the function with more information via a
call to otherclass#to_whatever_i_am.  You can do something like this:
class Frob
   attr_reader :val
   def initialize(i)
       @val = i
   end
   def to_frob
      self
   end
   def +(rhs)
      rhsF = rhs.to_frob
      Frob.new(rhsF.val + @val)
   end
end
class Integer
   def to_frob
       Frob.new(self)
   end
end
class Array
   def sum
       foldl(0) {|acc,x| acc + x}
   end
   def foldl(z)
      each {|x| z = yield(z,x)}
      z
   end
end
irb(main):055:0> [1,2,3].sum
=> 6
irb(main):057:0> [1,2,3].map {|x| Frob.new(x)}.sum
=> #
How do I extend Num, in this case?  Assign into the Integer namespace  
(maybe the wrong terminology, I don't know Ruby and don't want to)?   
I've considered designs like this, but they feel like a hack compared  
to type classes.
...
...
I'll agree with this point.  I've complained, concretely, about  
the lack of
instances for (some) standard types before.  (STM is actually a  
rather bad
offender here; it's lacking MonadPlus, as well, despite the specific
observation in the paper that it has the right signature for that  
class.)
Actually:
GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
Loading package base ... linking ... done.
Prelude> :m Control.Monad Control.Monad.STM
Prelude Control.Monad.STM Control.Monad> :i STM
...
instance MonadPlus STM -- Defined in Control.Monad.STM
OK.  I was going off the documentation (which is spotty for STM anyway).
...
...
When can we discharge a MaybeInstance context?
On any concrete type.  Like Typeable should be :)
The compiler then determines whether that type is an instance of the
class and provides the appropriate dictionary if applicable.
This works if orphan instances are outlawed.  That invalidates  
Haskell 98 programs, of course, including ones both of us have  
written.  Forbidding those would be an interesting language design  
choice, of course, and would make most of what you've asked for  
sensible.  Hmm.
...
...
Having the | Show a test suddenly trip from False to True because  
some
other module imported Text.Show.Functions sounds like an odd  
change to me.
At any rate, it scares me enough to make me oppose the idea.
I see the worry now.  I think this is more of a problem with orphan
instances; are orphan instances considered to be a valuable enough
feature to avoid potentially more powerful constructs?
Maybe there is a better solution to the "I have class C from library X
and type T from library Y and I want to make them play nice together"
problem than orphan instances.
I can't think of one, for the general case, but I guarantee I'll be  
worrying about both questions until I think I know the answer...

<snip>

jcc