On Thursday 12 March 2009 4:36:28 pm Thomas Hartman wrote:

http://blog.patch-tag.com/2009/03/09/implicitparams-are-evil-thoughts-on-ad apting-gitit/

I understand there are arguments for using IPs, but after this experience, the ImplicitParams extension is a "code smell" for me.

Implicit parameters are a (sort of) impure version of the reader monad. Of course, the 'effects' are still indicated in the type to a degree, but it's similar in a way to other languages which have impure IO (for example), except that reader is a lot less evil. :) The main thing they buy you, of course, is programming in a nice, normal, applicative style, instead of having to fool with monadic style (of course, they also give you multiple such variables, with names no less, that can be combined in a more dynamic fashion than Reader. To mimic all that (without passing around ST-like references), would probably require, off the top of my head, both indexed monads and extensible records. But I digress :)). Perhaps with applicative functor combinators, that gap can be lessened a bit. Incidentally, your example looks as follows with Reader: type ParamsHandler = Reader Params Handler withMessages :: [String] -> ParamsHandler -> ParamsHandler withMessages msgs val = local (\params -> params { pMessages = msgs ++ pMessages params }) val It'd be even nicer with lenses for updating the params. :) -- Dan

Thomas Hartman wrote:

http://blog.patch-tag.com/2009/03/09/implicitparams-are-evil-thoughts-on-ada...

I understand there are arguments for using IPs, but after this experience, the ImplicitParams extension is a "code smell" for me.

It's not just you. Implicit parameters are a scourge on the language. I think there are also some subtle annoyances with how they make apparently 'safe' program rearrangements unsafe, by pushing around "let ?foo = bar in ..." bindings.