Hi Daniel, in my game the handlers are supplied by the players as part of little programs that they submit. An haskell interpreter is reading the program code submitted and inserts it in the game. So there is an infinite number of handlers... I was thinking of hiding the parameters of the handlers like this: data Exp a where OnEvent :: EventName -> Exp () -> Exp () getArg :: Exp Int setArg :: Exp () deriving (Show) Now it should be possible to write the Show instance: instance Show a -> Show (Exp a) where ... You could write a program like this: myProgram :: Exp () myProgram = do OnEvent NewPlayer (getArg >>= (\name -> output $ "Hello to player " ++ name)) But I don't find it elegant at all: there is no compile time guaranty that the caller will set the argument correctly as you can have with normal function signatures... Best, Corentin On Sun, Mar 24, 2013 at 6:25 PM, Daniel Trstenjak < daniel.trstenjak@gmail.com> wrote:
Hi Corentin,
I have a DSL like this: data Exp where OnEvent :: EventName -> (Int -> Exp) -> Exp (...)
The "OnEvent" element carries a function (the handler to be called when the event happens), and that makes my DSL non showable/serializable. How could I fix that? This is a real handicap not to be able to serialize the state of my whole application because of that :)
You could have a unique id for your handlers, which might be an Int or a String and have some kind of registration for the handlers.
data Exp where OnEvent :: EventName -> HandlerId -> Exp
type HandlerId = String type Handler = (Int -> Exp) type Handlers = HashMap HandlerId Handler
registerHandler :: Handlers -> (HandlerId, Handler) -> Handlers getHandler :: Handlers -> HandlerId -> Maybe Handler
But you have to ensure, that for each application run the same HandlerId also gets the same Handler.
Less flexible but more secure is an ADT for you Handler.
data Handler = DoThat | DoSometingElse
You can than just pattern match on your handler and don't need any kind of registration.
But you can go further and define your own little Handler DSL.
Greetings, Daniel
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe