On 12/30/2012 10:57 PM, Eli Frey wrote:
sorry, forgot to reply-all

---------- Forwarded message ----------
From: *Eli Frey* <eli.lee.f...@gmail.com <mailto:eli.lee.f...@gmail.com>>
Date: Sun, Dec 30, 2012 at 1:56 PM
Subject: Re: [Haskell-cafe] Object Oriented programming for Functional
Programmers
To: Brandon Allbery <allber...@gmail.com <mailto:allber...@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'.



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to