On Tue, 16 Sep 2003 23:28:43 -0700
Ashley Yakeley <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Derek Elkins <[EMAIL PROTECTED]> wrote:
>
> > > I don't think this type is an arrow. For a "product arrow", i.e.
> > > an instance of Hughes' "Arrow" class with "first" defined, you can
> > > define this:
> >
> > Oh, it's definitely an arrow.
>
> I don't think you can make it an instance of Hughes' Arrow without
> some function for combining Strings.
It's not an arrow the way Yu Di wanted it, but it is an arrow. Which
arrow it is was part of my point in the latter paragraphs.
Here's the StateFunctor from Hughes' paper:
type StateFunctor s a b c = a (b,s) (c,s)
Using String for s and (->) for a we get:
type StringStateArrow b c = (b,String) -> (c,String)
alternatively, looking at the Kleisli arrow with m being the State monad
we get:
type Kleisli m a b = a -> m b
type StateM s a = s -> (a,s)
type StateA s a b = Kleisli (StateM s) a b
type StateA s a b = a -> s -> (b,s)
type StateA s a b = (a,s) -> (b,s)
type StringState a b = (a,String) -> (b,String)
or, if we do combine Strings we get something like the Writer monad:
type Monoid m => WriterM m a = (a,m)
type Monoid m => WriterA m a b = Kleisli (WriteM m) a b
type Monoid m => WriterA m a b = a -> (b,m)
type StringWriterA a b = a -> (b,String)
where mempty = [] and mappend = (++)
In either of these cases, there is not much reason to use an arrow over
a monad if it's the only arrow you are using and there are reasonable
reasons to use a monad over an arrow. Neither of these do what Yu Di
apparently wanted. In the more recent post by Yu Di, an arrow or monad
looks more appropriate, though for different reasons and in a different
way, which just goes to show that when posting one should state what
the ultimate goal is.
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
