Fwd: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether?

On Mon, Aug 18, 2008 at 2:02 PM, Henning Thielemann wrote:

On Mon, 18 Aug 2008, Bjorn Buckwalter wrote:

...

On Mon, Aug 18, 2008 at 11:16 AM, Henning Thielemann wrote:

...

On Mon, 18 Aug 2008, Bjorn Buckwalter wrote:

...

I would like to know if there is any consensus on what is the best way to make such a data structure accessible in pure functions. Passing it explicitly would be a mess. It seems that two options are to use either a Reader monad or implicit parameters. Using a Reader monad is straight forward enough though it requires writing/converting code in/to monadic style and adds some clutter to the formulae. It seems implicit parameters could be cleaner but I've seen them referred to as everything from evil to "just what you need" and rendering the Reader monad obsolete...

I expect that you will get the same range of opinions as you got from your search. As far as I know implicit parameters break referential transparency.

http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/FunWithLinearImpl... So I prefer Reader monad. The burden of converting to monadic style pays off when you need to use the same code with different values for the "constants". (E.g. find out for which value of the Planck constant the universe collapses and for which it oscillates etc. :-)

Love the example but could you elaborate a little on how monadic style helps with this? (This is probably a matter of it not being obvious to me what approach you would take to solving the problem.)

Instead of muEarth :: GravitationalParameter a muEarth = ???

escapeVelocity :: a escapeVelocity = ... muEarth ...

you would write

data AstroData a = AstroData { muEarth :: GravitationalParameter a , leapSeconds :: LeapSecondTable }

escapeVelocity :: Reader (AstroData a) a escapeVelocity = do mu <- asks muEarth return (... mu ...)

Even better you would introduce a newtype for Reader (AstroData a). This way you can add any monadic functionality later (Writer et.al.).

Right, and I'd evaluate it using e.g.: runReader escapeVelocity myAstroData But with implicit params I suppose I'd define (untested) e.g.: escapeVelocity :: (?astro :: AstroData a) => a escapeVelocity = ... mu ... where mu = muEarth ?astro To evaluate this I'd use: let ?astro = myAstroData in escapeVelocity Which is comparable to the Reader version (with the advantage/disadvantage of the body of 'escapeVelocity' not being monadic). In retrospect I think I misunderstood what you were saying in you first email. I thought you were arguing that the monadic style would have an advantage over implicit params in the Planck problem. But you probably only meant to reemphasize the advantage (of either solution) over hard-coding constants... Thanks again, your Reader example is virtually identical to what I started off with so at least I know I'm not completely off target for a monadic implementation. (Sorry about the reposts Henning, I keep forgetting to cc the café!)