Multiple Interpretations for a monad?
Hi everyone, in my attempts to remove boilerplate and thus to do more "abstraction" I come across a number of interesting things and suggestions. Especially blog posts from Dan Piponi and also Heinrich Apfelmus. I think what they both are saying is that you can construct / implement some sort of 2 layered monad which can then have more than one interpretation. In the responses to one of my posts on DSLs Dan Piponi also points out that he considers monads also to be DSLs. It didn't click with me when he said it, but reading more of his blog posts made me remember that. Now I know this is probably something obvious to most haskellers, but to me it's not. Did I understand this correctly so far? Günther
Monads aren't necessarily EDSLs by themselves but are often shipped with functions that provide what would make them an EDSL. Take the State monad, it has at least a get and a put function to work with the state in the monad. That get and put are commands that function only within the domain of the State monad, and therefore could be thought of as an embedded language that is used to work with the state encapsulated in the State Monad computation. The way I like to think of it, a Monad provides an environment or a context within which it is very convenient to express an EDSL, and that this style of coding should be encouraged! :-) Dave 2010/2/25 Günther Schmidt <gue.schmidt@web.de>
Hi everyone,
in my attempts to remove boilerplate and thus to do more "abstraction" I come across a number of interesting things and suggestions.
Especially blog posts from Dan Piponi and also Heinrich Apfelmus. I think what they both are saying is that you can construct / implement some sort of 2 layered monad which can then have more than one interpretation.
In the responses to one of my posts on DSLs Dan Piponi also points out that he considers monads also to be DSLs. It didn't click with me when he said it, but reading more of his blog posts made me remember that.
Now I know this is probably something obvious to most haskellers, but to me it's not.
Did I understand this correctly so far?
Günther
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
To take this a step further, there is the DSL: get :: m S put :: S -> m () and the concrete implementation m = State S Of course, there are other monads which implement this DSL as well: m = StateT S IO m = Prompt StatePrompt with data StatePrompt a where Get :: StatePrompt S Put :: S -> StatePrompt () The "Prompt" solution(1) encodes your program (object of type Prompt StatePrompt a) into a way such that it can be used with *any* interpreter, whether it is the (s -> (a,s)) of State, or lifted into part of some larger DSL, or whatever. For example, to lift into StateT S IO: interpretPrompt :: Prompt StatePrompt a -> StateT S IO a interpretPrompt = runPromptM f where f :: StatePrompt a -> StateT S IO a f Get = get f (Put x) = put x So, I think a better way to describe it is that a DSL could be implemented by many monads, and some monads let you interpret the DSL into another monad. Even StateT is this way, in a sense; you interpret it with runStateT: runStateT myProgram initialState :: IO (S, a) Now you have another program in a different monad (IO) which you need to interpret somehow. -- ryan (1) http://hackage.haskell.org/package/MonadPrompt 2010/2/25 David Leimbach <leimy2k@gmail.com>:
Monads aren't necessarily EDSLs by themselves but are often shipped with functions that provide what would make them an EDSL. Take the State monad, it has at least a get and a put function to work with the state in the monad. That get and put are commands that function only within the domain of the State monad, and therefore could be thought of as an embedded language that is used to work with the state encapsulated in the State Monad computation. The way I like to think of it, a Monad provides an environment or a context within which it is very convenient to express an EDSL, and that this style of coding should be encouraged! :-) Dave 2010/2/25 Günther Schmidt <gue.schmidt@web.de>
Hi everyone,
in my attempts to remove boilerplate and thus to do more "abstraction" I come across a number of interesting things and suggestions.
Especially blog posts from Dan Piponi and also Heinrich Apfelmus. I think what they both are saying is that you can construct / implement some sort of 2 layered monad which can then have more than one interpretation.
In the responses to one of my posts on DSLs Dan Piponi also points out that he considers monads also to be DSLs. It didn't click with me when he said it, but reading more of his blog posts made me remember that.
Now I know this is probably something obvious to most haskellers, but to me it's not.
Did I understand this correctly so far?
Günther
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Ryan Ingram wrote:
To take this a step further, there is the DSL:
get :: m S put :: S -> m ()
and the concrete implementation
m = State S
Of course, there are other monads which implement this DSL as well:
m = StateT S IO
m = Prompt StatePrompt with data StatePrompt a where Get :: StatePrompt S Put :: S -> StatePrompt ()
Elaborating on that, the DSL consists of two specific functions get, put and two general function (>>=), return Every combination of those is a program in the DSL. Example programs: get >>= put get >>= \x -> return (x,x) put 1 >>= \() -> get >>= \x -> return (2*x) This is the *syntactic* part of the DSL. Of course, we also need *semantics*, and those are given by an interpreter function. Examples: interpret :: m a -> (S -> a) interpret :: m a -> (S -> (a,S)) interpret :: m a -> StateT S IO a When the state monad is implemented as m a = S -> (a,S) this function is just the identity interpret :: (S -> (a,S)) -> (S -> (a,S)) interpret = id but as the MonadPrompt or operational packages show, this does not need to be the case; it is, in fact, beneficial to use a generic representation for the syntax and make the interpret function do all the work. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com
participants (4)
-
David Leimbach -
Günther Schmidt -
Heinrich Apfelmus -
Ryan Ingram