Maybe I'm just being blind here, but I don't see a monad transformer (or even a monad) in the standard libraries for producing "unique" values. Have I missed something? Related, I don't see a monad for gradually consuming input. We've got the Reader monad, but that appears to just give you global access to a single monolithic value. That value could be some kind of collection, but there's no way to track where you've read up to (or efficiently access that point). We've got Parsec, which is a pretty efficient and powerful text parser. But what if you don't need full parsing capabilities? You just need to consume input, but you're not exactly sure where you're going to consume it? The Writer monad seems to let you incrimentally write values out, but there's no matching monad for incrimentally reading stuff back in. (I guess ultimately you can build all these specialised monads out of the general State monad if you want. I'm just surprised they're not already defined somewhere...)
At Mon, 30 Mar 2009 20:29:14 +0100, Andrew Coppin wrote:
Maybe I'm just being blind here, but I don't see a monad transformer (or even a monad) in the standard libraries for producing "unique" values. Have I missed something?
There is Data.Unique http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Unique.html Not sure if that is suitable for your needs. Obviously it doesn't do everything that one might desire.
Related, I don't see a monad for gradually consuming input. We've got the Reader monad, but that appears to just give you global access to a single monolithic value.
(I guess ultimately you can build all these specialised monads out of the general State monad if you want. I'm just surprised they're not already defined somewhere...)
I have written a Consumer monad, but I never uploaded it to hackage, because, as you say, it seemed like it should just be a specialized version of the State monad?. It's here: http://www.n-heptane.com/nhlab/repos/haskell-consumer/ If people think it is actually valuable, I'll upload it. I would be interested in hearing some debate about what I wrote, versus just implementing it on top of the State monad, if anyone has something to say about that. Since the Reader and Writer monads could be implemented as specialized version of State, maybe that is an argument for implementing Consumer as I have? (Also, I get the feeling this Consumer monad already exists somewhere else?). - jeremy
On Mon, Mar 30, 2009 at 12:40 PM, Jeremy Shaw
At Mon, 30 Mar 2009 20:29:14 +0100, Andrew Coppin wrote:
Maybe I'm just being blind here, but I don't see a monad transformer (or even a monad) in the standard libraries for producing "unique" values. Have I missed something?
There is Data.Unique
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Unique.html
Not sure if that is suitable for your needs. Obviously it doesn't do everything that one might desire.
Related, I don't see a monad for gradually consuming input. We've got the Reader monad, but that appears to just give you global access to a single monolithic value.
(I guess ultimately you can build all these specialised monads out of the general State monad if you want. I'm just surprised they're not already defined somewhere...)
I have written a Consumer monad, but I never uploaded it to hackage, because, as you say, it seemed like it should just be a specialized version of the State monad?.
It's here:
http://www.n-heptane.com/nhlab/repos/haskell-consumer/
If people think it is actually valuable, I'll upload it. I would be interested in hearing some debate about what I wrote, versus just implementing it on top of the State monad, if anyone has something to say about that.
Since the Reader and Writer monads could be implemented as specialized version of State, maybe that is an argument for implementing Consumer as I have? (Also, I get the feeling this Consumer monad already exists somewhere else?).
One could argue that we don't need implementations any Monad, with perhaps the exception of IO :-) Dave
- jeremy _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
I think Data.Unique is horrible and should be banned.
It encourages a global variable style of programming that will just
bite you in the end.
-- Lennart
On Mon, Mar 30, 2009 at 8:40 PM, Jeremy Shaw
At Mon, 30 Mar 2009 20:29:14 +0100, Andrew Coppin wrote:
Maybe I'm just being blind here, but I don't see a monad transformer (or even a monad) in the standard libraries for producing "unique" values. Have I missed something?
There is Data.Unique
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Unique.html
Not sure if that is suitable for your needs. Obviously it doesn't do everything that one might desire.
Related, I don't see a monad for gradually consuming input. We've got the Reader monad, but that appears to just give you global access to a single monolithic value.
(I guess ultimately you can build all these specialised monads out of the general State monad if you want. I'm just surprised they're not already defined somewhere...)
I have written a Consumer monad, but I never uploaded it to hackage, because, as you say, it seemed like it should just be a specialized version of the State monad?.
It's here:
http://www.n-heptane.com/nhlab/repos/haskell-consumer/
If people think it is actually valuable, I'll upload it. I would be interested in hearing some debate about what I wrote, versus just implementing it on top of the State monad, if anyone has something to say about that.
Since the Reader and Writer monads could be implemented as specialized version of State, maybe that is an argument for implementing Consumer as I have? (Also, I get the feeling this Consumer monad already exists somewhere else?).
- jeremy _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On the other hand, I find its use in Control.Timeout to be perfectly sane (or at least as sane as anything else in that particular library). Cheers, Sterl. On Mar 30, 2009, at 4:42 PM, Jeremy Shaw wrote:
At Mon, 30 Mar 2009 20:57:02 +0100, Lennart Augustsson wrote:
I think Data.Unique is horrible and should be banned. It encourages a global variable style of programming that will just bite you in the end.
Agreed. I'm ashamed I even mentioned it.
- jeremy _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
G'day all.
Quoting Lennart Augustsson
I think Data.Unique is horrible and should be banned. It encourages a global variable style of programming that will just bite you in the end.
In the sense that it doesn't give you anything that Monad.Supply or Control.Comonad.Supply doesn't, I agree. However, Data.Unique is a building block for the grubby implementation details of prettier, higher-level data structures (e.g. data structures that use hash consing). It's not supposed to be used at the application level. In that sense, it's no worse than unsafePerformIO. Cheers, Andrew Bromage
Well, there are a few approaches available.
On the supply front you have the MonadSupply and MonadUnique proposals from
the wiki:
http://www.haskell.org/haskellwiki/New_monads/MonadSupply
http://www.haskell.org/haskellwiki/New_monads/MonadUnique
and of course, the ability to roll your own using the State monad.
Somewhat more satisfying at least my my esoteric interests, is that if
you're willing to turn your entire thinking on its ear there is a unique
supply comonad.
http://comonad.com/haskell/category-extras/dist/doc/html/category-extras/Con...
which I seem to recall was also available as Data.Supply.
The main issue with generalizing consumption of input is what does it
entail? when you are parsing a list do you have one element at a time
consumption? or do you have the ability to grab a whole prefix at once?
These issues tend to push you towards the use of the State monad anyways.
-Edward Kmett
On Mon, Mar 30, 2009 at 3:29 PM, Andrew Coppin
Maybe I'm just being blind here, but I don't see a monad transformer (or even a monad) in the standard libraries for producing "unique" values. Have I missed something?
Related, I don't see a monad for gradually consuming input. We've got the Reader monad, but that appears to just give you global access to a single monolithic value. That value could be some kind of collection, but there's no way to track where you've read up to (or efficiently access that point). We've got Parsec, which is a pretty efficient and powerful text parser. But what if you don't need full parsing capabilities? You just need to consume input, but you're not exactly sure where you're going to consume it? The Writer monad seems to let you incrimentally write values out, but there's no matching monad for incrimentally reading stuff back in.
(I guess ultimately you can build all these specialised monads out of the general State monad if you want. I'm just surprised they're not already defined somewhere...)
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
2009/03/30 Edward Kmett
The main issue with generalizing consumption of input is what does it entail? when you are parsing a list do you have one element at a time consumption? or do you have the ability to grab a whole prefix at once? These issues tend to push you towards the use of the State monad anyways.
You could approach that by stacking a supplier of prefixes on top of a supplier of elements (the first supplier supplies `a`, the second supplies `[a]`). That particular case doesn't force us out of generalized consumption as long as we are interested in stacking consumption. -- Jason Dusek
Andrew Coppin wrote:
Maybe I'm just being blind here, but I don't see a monad transformer (or even a monad) in the standard libraries for producing "unique" values. Have I missed something?
http://haskell.org/haskellwiki/New_monads/MonadSupply linked to from: http://www.haskell.org/haskellwiki/Monad#Interesting_monads
If you want one to generate names inside of a compiler. Here is a monad that is specialized to provide features useful for that. (like keeping track of in scope bound names independently of new names that arn't available for binding when renaming mutually recursive bindings as a group). Feel free to consider it public domain. http://repetae.net/repos/jhc/Util/NameMonad.hs John -- John Meacham - ⑆repetae.net⑆john⑈
participants (10)
-
ajb＠spamcop.net -
Andrew Coppin -
David Leimbach -
Edward Kmett -
Jason Dusek -
Jeremy Shaw -
John Meacham -
Lennart Augustsson -
Martijn van Steenbergen -
Sterling Clover