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

[Bjorn Buckwalter]

On Mon, Aug 18, 2008 at 2:02 PM, Henning Thielemann
<lemming at henning-thielemann.de> wrote:
>
> On Mon, 18 Aug 2008, Bjorn Buckwalter wrote:
>
>> On Mon, Aug 18, 2008 at 11:16 AM, Henning Thielemann
>> <lemming at henning-thielemann.de> 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/FunWithLinearImplicitParameters
>>>  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é!)