suggestions for improving MonadWriter
iavor.diatchki at gmail.com
Tue Jan 29 08:31:58 CET 2013
just for the record, this split is already made in `MonadLib` (e.g.,
monadLib's `collect` method, which corresponds to what Petr called
`contained`, is in its own class called `RunWriterM`; there are similar
classes for readers and exceptions).
On Mon, Jan 28, 2013 at 9:49 AM, Edward Kmett <ekmett at gmail.com> wrote:
> To be clear, I'm not yet making a concrete proposal for breaking up
> MonadReader and MonadWriter. Doing so would be fairly painful for at least
> some users in the short term. There are a lot of custom MonadReader and
> MonadWriter instances out there, and it also affects the signature of all
> combinators that consume these types that use pass, local or listen. That
> said the latter is probably only about 10% of the code that uses ask/tell.
> Moreso in the reader case than the writer case.
> Given the number of users who have to support multiple platform releases,
> a concrete proposal would have to address the upgrade path, possibly
> including making MonadLocal and MonadListen stub subclasses a version or so
> early and then moving methods over later, etc. so users can upgrade
> appropriately, and library authors can follow suit, permitting both an
> upgrade path or deciding to rip the bandaid off in one go. The logistics of
> this are somewhat convoluted, and if we're going to go through that pain,
> it may be worth addressing other concerns at the same time.
> On Jan 28, 2013, at 12:10 PM, Petr P <petr.mvd at gmail.com> wrote:
> 2013/1/28 Edward A Kmett <ekmett at gmail.com>
>> I've often wanted to remove the Monoid constraint, so I'm a strong +1 on
>> the first one.
>> The second one I'm -1 on, given that it can be expressed with the
>> existing combinators and due in small part to a more ideological concern:
>> Over time I've come to view cramming pass/listen and local into the
>> respective MonadWriter and MonadReader classes as a mistake. If we had the
>> hierarchy to do over, I'd probably want them split into separate
>> subclasses. This would permit more instances involving Cont, logging to
>> disk, etc.
> I strongly support your idea. Currently, MonadWriter and MonadReader just
> reflect ReaderT and WriterT so that we can make monad stacks. But they
> don't reflect the ideas - a monad we write to or read from, without any
> additional constraints. I'd really love to have them split up: A more
> general class that has just 'tell' and 'writer', and another that also has
> 'listen' and 'pass' (perhaps also 'contained').
> I tried to discuss it in haskell-cafe once <http://www.mail-archive.com/
> haskell-cafe at haskell.org/msg101756.html>, but without any feedback on the
> idea, so I thought everybody is happy with the current state.
> In this case, it seems that nothing important would break by this change,
> because IMHO there are very very little custom instances of
> MonadWriter/Reader. I'm also a big fan of this proposal: http://hackage.
> If it were implemented and standardized, we could refactor type classes
> without breaking existing code (or breaking it just very little).
> [In particular, it'd be possible to make Monad a subclass of Applicative,
> something I've always regretted we don't have.]
> Other than that, I'm not sure how adding "contained" goes against this
> idea. If we split MonadWriter into two type classes, "contained" would
> simply go into the one with "listen" and "pass".
> Best regards,
>> Also, the former can be done purely within the mtl, while the latter
>> drags transformers into it.
>> On Jan 27, 2013, at 3:30 PM, Petr P <petr.mvd at gmail.com> wrote:
>> Dear maintainers,
>> I have two suggestions for MonadWriter:
>> (1) Remove the "Monoid w" constraint from the definition.
>> The constraints prevent creating new instances of the class that have
>> only an implied monoid. For example, I needed to create a simple writer
>> which always stores the last written element. I had to wrap it into Last,
>> which was a nuisance for users of my library. Without the constraint, my
>> instance would be quite simpler and still satisfying all the laws. There
>> are many other similar use cases, like counting the number of written
>> values (and disregarding their actual content) etc.
>> The constraint is meant to ensure that instances of that class obey the
>> monad laws. But it's not the responsibility of a type class that its
>> instances satisfy the laws. They could violate them even without this
>> constraints. Instead, this constraint should be specified (and it is) in
>> the definition of their instances.
>> It has been discussed in haskell-cafe <http://www.haskell.org/pipermail/
>> haskell-cafe/2012-December/thread.html#105088> with arguments for and
>> (2) Add
>> -- | @contained m@ executes the action @m@ in a contained environment
>> -- returns its value and its output. The current output is not
>> contained :: m a -> m (a, w)
>> to MonadWriter.
>> This generalizes "pass" and "listen" and has it's a sort of inverse to
>> "writer" with these simple laws:
>> writer <=< contained = id
>> contained . writer = return
>> It seems as a understandable set of laws that its instances should obey.
>> It also expresses the same concept as "runWriterT" does, but inside the
>> type class. In particular, for "WriterT" we have
>> contained :: (Monoid w, Monad m) => WriterT w m a -> WriterT w m (a, w)
>> contained = lift . runWriterT
>> Current instances won't be affected as "contained" can be expressed using
>> "pass" and "listen" (and vice versa).
>> Full details available at
>> [There "contained" is expressed without the "Monoid w" constraint as
>> suggested in (1). If we keep the constraint, "contained" can be expressed
>> more simply as
>> containde k = pass (listen k >>= \x -> return (x, const mempty)).
>> Also, "contained" isn't probably a good name, I just couldn't think of
>> anything better.]
>> Best regards,
>> Petr Pudlak
>> Libraries mailing list
>> Libraries at haskell.org
> Libraries mailing list
> Libraries at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries