[Haskell] Rebindable syntax for monads and arrows
Arthur van Leeuwen
arthurvl at cs.uu.nl
Mon Jan 17 05:48:19 EST 2005
On 07 jan 2005, at 17:53, Amr A Sabry wrote:
> Greetings all,
>
> This message is a sort of a poll to find out how much interest the
> community
> has in an implementation of rebindable syntax for monads and arrows.
> You can
> send your answers directly to me (sabry ... indiana edu) and I will
> summarize
> to the list if appropriate.
>
> An example using monads
> -----------------------
>
> The type Vec below is almost a monad:
> - the operations vreturn and @>>= are almost of the right type
> (they have an additional constraint FinSet a =>)
> - the operations vreturn and @>>= satisfy the monad laws
>
> class Eq a => FinSet a where enumerate :: [a]
>
> newtype Vec a = Vec (a -> Float)
> unV (Vec f) = f
>
> vreturn :: FinSet a => a -> Vec a
> vreturn a = Vec (\ b -> if a==b then 1 else 0)
>
> (@>>=) :: FinSet a => Vec a -> (a -> Vec b) -> Vec b
> (Vec va) @>>= f = Vec (\ b -> sum [ (va a) * (unV (f a) b) |
> a <- enumerate])
>
> Because of the additional type constraint (FinSet a =>) we cannot make
> the
> type Vec an instance of the class Monad, and hence we cannot use the
> do-notation to express our computations.
>
> -----------------------------------------------------------------------
> ------
> Question I
> -----------------------------------------------------------------------
> ------
>
> Do you have other examples, where you wished you could define
> instances of
> the class Monad with operations whose types are more constrained than
> required? Or more generally do you feel that allowing such a behavior
> is
> worthwhile?
A resounding yes to that one. Both of them. The example I have is one
of trying
to put numerical values under the identity monad and then record
expressions
on those values within the monad itself. This was somewhat hampered by
the
impossibility of putting additional type constraints on instances of
Monad.
> -----------------------------------------------------------------------
> ------
> Question II
> -----------------------------------------------------------------------
> ------
>
> Arguably the do-notation for monadic computations is nice but the
> overhead of
> writing using explicit combinators is not that bad. The situation for
> arrows
> is quite different: the syntactic sugar for arrows is almost essential
> and it
> often expands into something you _do_not_want_to_write_
>
> So, do you have examples, where you wished you could define instances
> of the
> class Arrow with operations whose types are more constrained than
> required?
Unfortunately not, but I must admit to not having played with Arrows.
Might be a
nicer idiom for what I'm doing though...
Doei, Arthur.
--
arthurvl at cs.uu.nl | Work like you don't need the money
A friend is someone with whom | Love like you have never been hurt
you can dare to be yourself | Dance like there's nobody watching
More information about the Haskell
mailing list