Does anybody dislike implicit params as much as I do?
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.
2009/3/12 Thomas Hartman
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.
I think you state the obvious for many haskellers, so no, you're not alone :) Thu
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
There is an old joke in Russia: - I don't like cats. - You just don't know how to cook them. Well, maybe, you don't know how to cook implicit parameters? Anyway, what about type classes - aren't they a sort of implicit parameters? On 12 Mar 2009, at 23:36, 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. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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.
Jules Bean wrote:
Thomas Hartman wrote:
http://blog.patch-tag.com/2009/03/09/implicitparams-are-evil-thoughts-
on-adapting-gitit/
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 they have a useful place in propagating semi-global configuration information without imposing huge syntactic overhead. I think using them like in the code referred to in the URL above, where their values are frequently changed down the call stack, is dangerous. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
Sittampalam, Ganesh wrote:
I think they have a useful place in propagating semi-global configuration information without imposing huge syntactic overhead.
Right, for instance, type MyMonad a = (?env :: Env) => IO a No lift needed! I was hoping to use IPs to do OO-style implicit type conversion from a "derived" type to "base" type. For instance: type Base = forall a. ((?f1 :: Int) => a) -> a field1 :: Base -> Int field1 b = b ?f1 type Derived = forall a. ((?f1 :: Int, ?f2 :: String) => a) -> a d :: Derived d x = let {?f1 = 3;?f2 = "Hello"} in x f1d :: Int f1d = field1 d Annoyingly, GHC objects to the "field1 d" application. -- Ashley Yakeley
participants (7)
-
Ashley Yakeley -
Dan Doel -
Jules Bean -
Miguel Mitrofanov -
minh thu -
Sittampalam, Ganesh -
Thomas Hartman