Here's another thought (not my own):
Abstractions can be classified based on where responsibility lies. Popular languages implementing interface composition expect the caller to know almost nothing about the concrete details while the callee has to handle all concrete permutations. Conversely, the sort of abstraction we see in typeclasses, much like those in c++ template programming, require the client to dictate concrete details that satisfy the callee requirements.
Cheers,
Darren
On 30/06/13, Dan Burton <danburton.email@gmail.com> wrote:One of the nice things about OO is the intuitive nature of the is-a relation between class and instance (forgetting hierarchies for the moment). I suggest that an intuitive interpretation of the Haskell class–instance relation might be *acts-as*. For example, a car or a bus could afford transport once they have a move operation. This is an intuitive view for design; it does not reflect the language level function of handling ad-hoc polymorphism. Also it reifies the type class, which AFAIK does not exist at run time.I am not trying to say "every building is a shelter", rather "anything that is a building must provide sheltering services".Well if it walks like a shelter and quacks like a shelter... /shrug
Tá an teachtaireacht seo scanta ó thaobh ábhar agus víreas ag Seirbhís Scanta Ríomhphost de chuid Seirbhísí Faisnéise, ITBÁC agus meastar í a bheith slán. http://www.dit.ie
This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe