Sorry if this mail starts a new thread. I am not subscribed to haskell-cafe and am new to hotmail. Uhm, as far as the example goes. I was trying to define a small (shallow encoding of) a reactive systems language. Because I wanted to try something else than monads I defined the following recursive type for a reactive system. type R m = m -> Maybe (R m, [m]) Supposedly a reactive system is a system which may not take a message (the Maybe), or do take it and respond with an updated version of itself, and a sequence of outgoing messages. For example, a copying machine might be defined as: id:R m id m = Just (id, [m]) A version for a ?Meally? machine embedding (always take an incoming message, and respond with one outgoing message) could be written as type Meally i o = i -> (Meally i o, o) where id is defined as id::Meally a a id m = (id, m) I like the formalization because (a) it is concise, (b) structural composition operators can be defined trivially, (c) hides the state of a machine, (d) might possibly, in the long run, somewhere, even work out equally well as a monadic approach. Does it make sense? Are there any known references to this approach? Cheers, l4t3r PS: Actually, I just realized this might be the co-algebraic approach, so I guess I am asking for a haskell which allows co-algebraic types. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
On Wed, Jul 16, 2003 at 02:01:36PM +0200, blaat blaat wrote:
Sorry if this mail starts a new thread. I am not subscribed to haskell-cafe and am new to hotmail.
Uhm, as far as the example goes. I was trying to define a small (shallow encoding of) a reactive systems language. Because I wanted to try something else than monads I defined the following recursive type for a reactive system.
type R m = m -> Maybe (R m, [m])
I don't think there's an extension of Haskell with regular type unification. It's certainly possible, but there's an equivalent in standard Haskell: newtype R m = MkR (m -> Maybe (R m, [m])) except for the nuisance of adding and removing the MkR constructor. Also, regular type trees would make type errors more hairy, and in Haskell one tends to write a lot of data's and newtype's anyway in order to define class instances. So co-algebraic programs are nothing special in Haskell, if you ignore that constructor.
A version for a ?Meally? machine embedding (always take an incoming message, and respond with one outgoing message) could be written as
type Meally i o = i -> (Meally i o, o)
This particular example is an instance of an arrow type, and is handy for simulating synchronous circuits, cf http://www.soi.city.ac.uk/~ross/papers/fop.html (look for "Simple automata" on the 3rd page) A more bizarre example is "hyperfunctions": newtype Hyper i o = Hyper (i -> Hyper o i) cf http://www.cse.ogi.edu/~krstic/psfiles/hyperfunctions.ps
Dnia śro 16. lipca 2003 14:34, Ross Paterson napisał:
type R m = m -> Maybe (R m, [m])
I don't think there's an extension of Haskell with regular type unification. It's certainly possible, but there's an equivalent in standard Haskell:
newtype R m = MkR (m -> Maybe (R m, [m]))
It will possibly be more convenient to break the cycle in another place, where we will wrap and pattern match anyway: type R m = m -> Response m data Response m | NotTaken | Taken (R m) [m] -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
participants (3)
-
blaat blaat -
Marcin 'Qrczak' Kowalczyk -
Ross Paterson