sorry, forgot to reply-all
-- Forwarded message --
From: Eli Frey
Date: Sun, Dec 30, 2012 at 1:56 PM
Subject: Re: [Haskell-cafe] Object Oriented programming for Functional
Programmers
To: Brandon Allbery
> 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.
On Sun, Dec 30, 2012 at 1:27 PM, Brandon Allbery wrote:
> On Sun, Dec 30, 2012 at 3:45 PM, Eli Frey wrote:
>
>> > mconcat :: Monad m => [m] -> m
>> > mconcat = foldl mappend []
>>
>> We can think of `mconcat` having a little lookup table inside of itself,
>> and whenever we pass it a concrete `[m]`, `mappend` gets looked up and we
>> get the implementation for `m`. Typeclasses are just mappings from types
>> to functions
>>
>
> Except not quite... the "Monad m =>" in the signature really means "hey,
> compiler, pass me the appropriate implementation of Monad so I can figure
> out what I'm doing with this type m". It's not a built in table, it's a
> hidden parameter.
>
> Aside from Object Orientation, it is probably a good idea to learn some C
>> for a bit too. C is a good language to play in and try and implement more
>> advanced language features. Once you reallize that objects are just lookup
>> tables of functions bound with a data-structure, you can implement your own
>> in C, or you can make closures as functions bundled with (some) of their
>> arguments, or you can implement interesting datastructures, or so many
>> other fun things. A good understanding of tagged unions has helped me in
>> many a convo with an OO head.
>>
>
> A perhaps strange suggestion in this vein: dig up the source code for Xt,
> the old X11 Toolkit, and the Xaw widget library that is built atop it.
> (It's part of the X11 source tree, since most of the basic X11 utilities
> and xterm are based on it.) It implements a primitive object system in C.
> Gtk+ does the same, but hides much of the implementation behind macros and
> relies on tricky casting etc. behind the scenes for performance; in Xt, the
> basic machinery is more easily visible for inspection and much easier to
> understand even if you're not all that familiar with C. If you go this
> way, once you've figured out what Xt is doing you might go on to see the
> more advanced concepts in how Gtk+ does it.
>
> And once you've done this, you'll have a good idea of what Objective-C and
> C++ (minus templates) are doing under the covers. (Mostly C++, since ObjC
> is more or less Smalltalk's OO on top of X, whereas the core concepts of
> C++ are not so very different from what Xt does.) If you really want to
> dig in further, you might want to try to find the source to cfront, the
> original C++ implementation which was a preprocessor for the C compiler.
> It'll be missing a lot of modern C++ features, but the core is there.
>
> --
> brandon s allbery kf8nh sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
