Motivating the Use of Purely Functional Programming Techniques

Over time I’ve seen, and read, and presented quite a lot of motivations for the use of purely functional programming — sometimes for Haskell, Lisp, or ML. Today I’ve seen the first motivation/introduction which did not come from a mathematical/categorical perspective. That was quite refreshing. You can find it here.

Although, there is nothing really new in it — at least not for someone who has been following Haskell for 10 years now — this is a nicely presented new angle on the topic. So, have a look at that talk and see for yourself.

This entry was posted in General, Programming and tagged , , , , , , . Bookmark the permalink.

One Response to Motivating the Use of Purely Functional Programming Techniques

  1. Sam says:

    There’s at least one big exception to this being a good rule: csselas with somehow mutually definable methods. For instance, Ordclass Ord a where compare :: a -> a -> Ordering ( a -> Bool …It actually has a lot of methods, and sensibly so, because any one of several works as the default (although, the defaulting facilities could be buffed as well: let me specify all possible defaults, with implementations in terms of each, instead of working out an implicit graph with one or two possible nodes like now).Another I want is:class … => Monad m where (>>=) :: m a -> (a -> m b) -> m b join :: m (m a) -> m aI should be able to pick which I want to define. Or both if I want. And allowing me to override some more specific combinators isn’t a bad idea either, like the new Functor:class Functor f where fmap :: (a -> b) -> f a -> f b ( f b -> f aApplicative and Monad are likely to have similar possible, this could be significantly more efficient for some implementations, methods. People seem averse to this sort of thing (and often suggest RULEs instead, which are unportable), but I don’t really see the problem with indulging a bit (you can obviously go overboard).As an additional aside: I’m not sure we can blame the various kinds of failure’ mess on multiple methods specifically. It’s a combination of factors.1. fail exists for dubious reasons that don’t have to do with a separate class. Failure was specifically intended to be possible for every Monad in H98.2. Alternative exists separately from MonadPlus because the latter predates Applicative, but there’s no reason to require all MonadPlusses to be a Monad. So it’s a hierarchical (and legacy code) issue.3. Monoid exists apart from the others (at least) because you cannot write a constraint like (forall a. Monoid (m a)). So it’s a type system issue.Anyhow, I don’t see anything wrong with one-function-per-class as a basic guideline, but I wouldn’t want it to be enforced by the language for instance (like it used to be in Clean).

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>