[Haskell-cafe] Fwd: Object Oriented programming for Functional Programmers

[Timon Gehr]

On 12/30/2012 10:57 PM, Eli Frey wrote:
> sorry, forgot to reply-all
>
> ---------- Forwarded message ----------
> From: *Eli Frey* <eli.lee.frey at gmail.com <mailto:eli.lee.frey at gmail.com>>
> Date: Sun, Dec 30, 2012 at 1:56 PM
> Subject: Re: [Haskell-cafe] Object Oriented programming for Functional
> Programmers
> To: Brandon Allbery <allbery.b at gmail.com <mailto:allbery.b at gmail.com>>
>
>
>  > Except not quite... [...] It's not a built in table, it's a hidden
> parameter.
>
> I'll admit this doesn't HAVE to be the implementation.  Often time the
> compiler can monomorphise the types and "perform the lookup" at compile
> time.
>
> But what's going on here tho.
>
>  > {-# LANGUAGE ExistentialQuantification #-}
>  >  data Showable = forall a. Show a => Showable a
>  >
>  > printShowable :: Showable -> IO ()
>  > printShowable (Showable x) = print x
>  >
>  >  main = mapM printShowable [ Showable "bob", Showable 3, Showable
> Nothing ]
>
> If we take `mapM printShowable` and just give it an arbitrary list, it
> has to lookup the correct implementations of `print` as it walks down
> that list at run-time.  I believe similar things motivate vtables in
> c++/java.  I don't have a strong intuition about how dynamically typed
> OO langs deal with this, but I'm sure structural typing has similar issues.
>
>...

The Showable constructor has two parameters. The 'Show' instance for 'a' 
(passed implicitly) and an 'a' (passed explicitly). When pattern 
matching, that instance gets unwrapped together with the payload. It is 
then implicitly passed to 'print', which finally uses it to look up the 
correct implementation of 'show'.