Iavor Diatchki [EMAIL PROTECTED] wrote:
class IxMonad m where
(=) :: m i j a - (a - m j k b) - m i k b
ret:: a - m i i a
And just for fun we can define another indexed monad:
state that supports strong updates (i.e., the type
of the state can change as you compute):
On Mon, Dec 18, 2006 at 06:52:41PM -0800, Iavor Diatchki wrote:
Hi David,
I don't think you need functional dependencies or associated
type synonyms to get your example to work. In the past,
I have used the abstraction that you are describing (I call it
an indexed monad and it has a nice
David Roundy wrote:
The trouble is that your solution doesn't allow you to use do-notation with
the IxMonad. And if you did allow yourself to use do-notation by rebinding
(=), etc, then you wouldn't be able to use ordinary monads with
do-notation in the same module. That's what makes things
On Tue, Dec 19, 2006 at 10:08:12AM -0500, Jacques Carette wrote:
David Roundy wrote:
The trouble is that your solution doesn't allow you to use do-notation with
the IxMonad. And if you did allow yourself to use do-notation by rebinding
(=), etc, then you wouldn't be able to use ordinary
On the FD impasse:
Witness.hs:33:0:
Couldn't match expected type `m'' (a rigid variable)
against inferred type `RealWitness a a''
`m'' is bound by the type signature for `' at Witness.hs:11:29
When using functional dependencies to combine
Witness WitnessReally a
First, I believe that this paper
http://homepages.inf.ed.ac.uk/ratkey/param-notions.pdf
is intimately related to WitnessMonad.
David Roundy wrote:
Rebinding the do notation is at least reasonably clean, it's just that we
don't want to lose the ability to mix with ordinary monads.
This
Hi,
On 12/19/06, Jacques Carette [EMAIL PROTECTED] wrote:
First, I believe that this paper
http://homepages.inf.ed.ac.uk/ratkey/param-notions.pdf
is intimately related to WitnessMonad.
This paper definitely seems to be related. Thanks for the link!
-Iavor
Hi David,
I don't think you need functional dependencies or associated
type synonyms to get your example to work. In the past,
I have used the abstraction that you are describing (I call it
an indexed monad and it has a nice categorical definition).
Here is how you can define it:
class
Here's a sketch of an idea as a solution to my dilemma, which unfortunately
requires associated types. Any suggestions how it might be translatable
into functional dependencies? (I should say, I've not got a HEAD ghc, and
am just going by memory on my indexed types syntax.)
class Witness w where
I've now almost got a FD solution to this problem, except that it won't
work, and I don't know why. Of course, it's possible that the AT solution
won't work either (I'm still compiling ghc, should have it in the
morning...), but at least it seems far simpler. My FD solution is below.
My trouble
10 matches
Mail list logo
