4 ms·
Very detailed and informative! For onlookers, I'd note that Haskell typeclasses are something of a trap for beginners who think they are the way to accomplish
by mbrock 9y ago
Very detailed and informative!
For onlookers, I'd note that Haskell typeclasses are something of a trap for beginners who think they are the way to accomplish object-like coding in Haskell.
Actually, records with functions (closures) inside is usually a better choice: simpler, more flexible, more straightforward.
Of course the resemblance between a vtable and a record of functions is very obvious!
- seanmcdirmid 9y agoRecords with adhoc v-tables was how we did it in C. It was incredibly useful given an existing object schema to model.
- jonahx 9y ago> they are the way to accomplish object-like coding in Haskell. > Actually, records with functions (closures) inside is usually a better choice: The better choice would be to use Haskell as it was intended to be used.
- mbrock 9y agoAnd that doesn't include first class functions inside of data structures? :)
- jonahx 9y agoI was just responding to "object-like coding," which i took to mean "using the OO paradigm in haskell." sorry if that's not what you meant.
- Gaelan 9y agoI assume “object-like coding” just means “a data structure and a set of functions for interacting with it. Are you implying that the “right way” of using Haskell doesn’t do anything like that?
- evincarofautumn 9y agoYup, generally in terms of program structure, when I would make a class in C++/C#/Java, I make a module in Haskell. There’s usually a primary type and some helper types exported, along with functions that form the public interface. If you need polymorphism you can mostly just reach for parametric polymorphism (generics) and closures. Existential types, in the form of closures, explicit existentially quantified types, or rank-2 universally quantified functions, give you basically the same expressive power as virtual functions—they’re all encodings of the same concept. Typeclasses are more about the principle of “code to the interface, not the implementation”. For example, using a container through its Functor/Applicative/Monad/Monoid/Traversable/Foldable instances lets you be agnostic to its representation, swap it out for testing/performance, &c.
- cies 9y ago> when I would make a class in C++/C#/Java, I make a module in Haskell. This. Group you code logically, expose only what's needed. This also gives the FPer a large part of the "encapsulation" and "group by responsibility" advantages that are often mentioned as pros of OO. Without going down the "implicit state sharing" path.
- catnaroek 9y agoEncapsulation works even better with modules than with objects: (0) Modules may expose n-ary operations on abstract types for n > 1. (1) Modules may have multiple interrelated abstract type components, i.e., what Stepanov calls “multisorted algebras”. Furthermore, if you are willing to use an impure language (like ML or Scala), modules can be just as stateful as objects if you deem it necessary.