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

On Mon, Aug 18, 2008 at 2:02 PM, Henning Thielemann
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é!)

Bjorn Buckwalter schrieb:
On Mon, Aug 18, 2008 at 2:02 PM, Henning Thielemann
wrote: 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 my opinion the implicit parameters don't make things simpler, only less portable, that's why I prefer the Reader monad.
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...
indeed

Which is comparable to the Reader version (with the advantage/disadvantage of the body of 'escapeVelocity' not being monadic).
In my opinion the implicit parameters don't make things simpler, only less portable, that's why I prefer the Reader monad.
They also seem to be removed from ghc: http://www.haskell.org/pipermail/cvs-ghc/2006-September/031824.html So it would probably be a mistake to write new code using them. As an aside, if that's really the complete patch I'm impressed how few lines were involved. 136 lines out of TcSimplify.lhs and misc tiny changes in other files.

On 2008 Aug 18, at 16:20, Evan Laforge wrote:
Which is comparable to the Reader version (with the advantage/disadvantage of the body of 'escapeVelocity' not being monadic).
In my opinion the implicit parameters don't make things simpler, only less portable, that's why I prefer the Reader monad.
They also seem to be removed from ghc:
http://www.haskell.org/pipermail/cvs-ghc/2006-September/031824.html
Again, that's *linear* implicit parameters (%foo instead of ?foo). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

They also seem to be removed from ghc:
http://www.haskell.org/pipermail/cvs-ghc/2006-September/031824.html
Again, that's *linear* implicit parameters (%foo instead of ?foo).
Oh, you're right. I made exactly the same mistake you made, and right after you warned against making it too. I always thought "linear" was the ? stuff, but now I see it's not. Maybe it's best that it's gone so we only have one flavor of "implicit parameters" feature from here on out.

On 2008 Aug 18, at 17:09, Evan Laforge wrote:
They also seem to be removed from ghc:
http://www.haskell.org/pipermail/cvs-ghc/2006-September/031824.html
Again, that's *linear* implicit parameters (%foo instead of ?foo).
Oh, you're right. I made exactly the same mistake you made, and right after you warned against making it too. I always thought "linear" was the ? stuff, but now I see it's not. Maybe it's best that it's gone so we only have one flavor of "implicit parameters" feature from here on out.
Don't feel too bad; the main reason I'm commenting on it is I managed to confuse a bunch of people in public before I was set straight on it, so I kinda feel a bit guilty when people are confused by it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
participants (4)
-
Bjorn Buckwalter
-
Brandon S. Allbery KF8NH
-
Evan Laforge
-
Henning Thielemann