3 ms·

Yup, 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 help

Yup, 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 ago
  Encapsulation 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.