- Libraries - Haskell.org

whenJust / forM_ (was Re: Proposal: Add isLeft/isRight to Data.Either)
by Conrad Parker 11 Dec '12

11 Dec '12

On 8 December 2012 02:38, Erik Hesselink <hesselink(a)gmail.com> wrote: > On Friday, December 7, 2012, Thomas Schilling wrote: >> >> On 7 December 2012 09:25, Erik Hesselink <hesselink(a)gmail.com> wrote: >> > There is no need to define whenJust, since it is just a specialization >> > of forM_ from Data.Foldable. >> >> I don't know if that's such a good argument. I prefer my code >> readable -- too much abstraction can have a seriously bad effect on >> that. As a simple rule, if the user has to do type inference in their >> head, readability suffers. >> >> In this case, "forM_" implies we're iterating over something container >> like, "whenJust" means "I want to do something if this thing yielded a >> result". It depends on the context whether a "Maybe" is behaving more >> container-like or is indicating the presence of a result where there >> may not have been one. > > > I don't have this problem, but I guess that's just personal. But in general > I'm not in favor of adding specialized versions of generalized functions. indeed, and likewise we should get rid of Control.Monad.forM_ :: Monad m => [a] -> (a -> m b) -> m () which is just the same specialization to lists (and likely the reason that forM_ doesn't come to mind for other container types, as much as I generally like Data.Foldable). btw: $ git grep whenJust|wc -l 40 Conrad.

2 2

Re: portable encoding/decoding without going via a handle
by Ganesh Sittampalam 10 Dec '12

10 Dec '12

Hi Judah, On 25/11/2012 17:19, Judah Jacobson wrote: > I think some way to use BufferCodecs without going through the > filesystem would be very useful. One other approach would be > Bytestring-backed Handles; there was talk of them in the past, but I > don't know of any actual packages for it yet. That might be a simpler > approach than manipulating BufferCodecs directly, since you could just > use the functions from Data.Text.IO <http://Data.Text.IO> and all of the > buffering and error recovery would get taken care of automatically. > > This 2009 email from Simon Marlow references bytestring-backed handles > and has a code sample for memory-mapped files that might be helpful: > http://www.haskell.org/pipermail/glasgow-haskell-users/2009-December/018124… > He also mentions bytestring-backed Handles in this talk: > http://community.haskell.org/~simonmar/GHC-IO.pdf > That code's probably bitrotted a little, but seems like a good place to > start. Thanks for the pointers! Do you have any thoughts on what the API for creating a bytestring-backed handle should be? I'm particularly thinking of the case where we are writing to the bytestring - the type could be something like makeWritableByteStringHandle :: IO (Handle, ByteString) but then would we end up with a ByteString value that could be being mutated in parallel with being used. It might be nicer to have it in two phases, e.g. makeWritableByteStringHandle :: IO Handle finishByteStringHandle :: Handle -> IO ByteString but since Handle is a single type rather than a type class, that's not imlpementable. Perhaps: makeWritableByteStringHandle :: IO (Handle, IO ByteString) where the embedded IO action is only valid after the Handle has been hClose'd? Cheers, Ganesh

2 2

[stm] strange behavior with TQueue and STM's alternative instance
by Patrick Palka 10 Dec '12

10 Dec '12

Hi, I'm getting strange behavior when using the 'many' combinator to read zero or more items off of a TQueue with readTQueue. The script that exhibits this behavior is as follows: import Control.Concurrent.STM import Control.Concurrent import Control.Monad import Control.Applicative main = do q <- newTQueueIO atomically $ writeTQueue q True atomically $ writeTQueue q False forever $ do xs <- atomically $ many $ readTQueue q print xs threadDelay 500000 I'd expect the output of the script to be: [True,False] [] [] ... However, that is not the case: the actual output of the script is: [True,False] [True,False] [True,False] ... This means that TQueue is incompatible with TChan, since if TQueue is replaced by TChan then the script behaves as one would expect. If 1 element (say, True) is written into the TQueue instead of 2, then the output of the script is: [True] [] [] ... Which is expected behavior, but inconsistent with the behavior when the TQueue has 2 or more elements in it. Is this considered a bug, or undocumented behavior of TQueue?

3 11

Re: Proposal: merge either into transformers
by Gabriel Gonzalez 08 Dec '12

08 Dec '12

If you add a 'catch' function to `either`, I recommend using the implementation of 'catchT' in the 'errors' package that lets you change the type of the left value so that it is symmetric to (>>=).

1 0

Growing Haskell Platform
by Mark Lentczner 07 Dec '12

07 Dec '12

In my Haskell Implementors 2012 talk Haskell Platform: Field Report and Future Goals, I called for an expansion of the content of the platform to bring it up to par with what other programming language platforms provide. Please see my blog post today: http://mtnviewmark.wordpress.com/2012/12/06/growing/) Where I outline what is missing, and call for a ramp up in our efforts to grow the platform. - Mark

9 12

yaml and aeson Was: Growing Haskell Platform
by Michael Snoyman 07 Dec '12

07 Dec '12

On Fri, Dec 7, 2012 at 10:54 AM, Roman Cheplyaka <roma(a)ro-che.info> wrote: > * Michael Snoyman <michael(a)snoyman.com> [2012-12-07 09:52:07+0200] > > Let me bring up one other package: yaml (written by me). I think it's a > > pretty good fit for the standard YAML packaging library, since it simply > > reuses the existing infrastructure from the aeson package (i.e. the > ToJSON > > and FromJSON typeclasses, and the Value datatype). But I'm actually a bit > > concerned about proposing it, based on some history. > > When I was looking at existing YAML libraries, I rejected yours when I > saw JSON types. (I did see the "do not let that confuse you, it's > intentional" warning, and no, it didn't help.) > > Besides giving the feeling that the API is a hack, this will inevitably > confuse readers of my code who are not familiar with the library and, > just based on the names, will assume that the code is working with JSON, > not YAML. > > If you mean the naming is a hack, I agree. But if we pretend for a moment that the word JSON was actually replaced with YAML everywhere, I think the abstraction is correct. The Value datatype represents a very sane subset of YAML that people usually want to deal with. And if they want to deal with all the glories of aliases and tags, we still have the Text.Libyaml interface which preserves all information. In other words, the hack is in the name, not the abstraction. > IIUC, "all of the existing tools for JSON processing" are mainly just > existing FromJSON instances. I am not sure how common this situation is, > but for that you could define a newtype whose FromYAML instance would > internally use the FromJSON instance of the underlying type. > > It's the two typeclasses and the Value datatype. Don't underestimate the importance of reusing infrastructure here. If we had our own types and classes in YAML, then everyone who wants to include serialization classes in their packages would have to write redundant instances for both packages. Most likely, that would just mean incomplete instances for both packages. It would also mean that we'd have to duplicate libraries like aeson-lens, and duplicate all bugfixes in built-in instances, Generics code, TH code, etc. As a side benefit, the current setup allows code to remain serialization-format-agnostic. For example, Persistent can read configuration from either JSON to YAML files. Since YAML is a superset of JSON, that's not such an amazing statement, but it does mean that users can avoid an extra yaml package dependency if they really are just sticking with JSON data. > Or perhaps the JSON-agnostic subset of aeson could be extracted into a > separate library, which both aeson and yaml would depend on. > > I'd be very much in favor of that. I'm not so irked by the "name hack" to have bothered bringing this up with Bryan, but if he's willing to make that change, I'd certainly be grateful. I actually think it would be more logical for the typeclasses to be called ToValue and FromValue anyway, since that more directly states what they do. > As for toYAML/toJSON, I guess most of the time they are different anyway — > otherwise it's defeating the purpose of YAML to be more human-readable > than JSON. > > I don't think that's true in practice. Most of the readability of YAML comes from the syntax, not the choice of actual serialization structure. But I could be mistaken. Michael

2 2

Re: yaml and aeson Was: Growing Haskell Platform
by Oren Ben-Kiki 07 Dec '12

07 Dec '12

YAML does provide additional power over JSON when it comes to serialization (in the form of !tags), so it seems that by using the same API you'd be giving up some power. Of course, if you decide to stick to the JSON subset and just use YAML for more readable syntax, the same API will work fine. Have fun, Oren Ben-Kiki On Fri, Dec 7, 2012 at 12:08 PM, Oren Ben-Kiki <oren(a)ben-kiki.org> wrote: > YAML does provide additional power over JSON when it comes to > serialization (in the form of !tags), so it seems that by using the same > API you'd be giving up some power. Of course, if you decide to stick to the > JSON subset and just use YAML for more readable syntax, the same API will > work fine. > > Have fun, > > Oren Ben-Kiki > > > On Fri, Dec 7, 2012 at 12:00 PM, Roman Cheplyaka <roma(a)ro-che.info> wrote: > >> * Michael Snoyman <michael(a)snoyman.com> [2012-12-07 11:51:40+0200] >> > > As for toYAML/toJSON, I guess most of the time they are different >> anyway — >> > > otherwise it's defeating the purpose of YAML to be more human-readable >> > > than JSON. >> > > >> > > >> > I don't think that's true in practice. Most of the readability of YAML >> > comes from the syntax, not the choice of actual serialization structure. >> > But I could be mistaken. >> >> Not the serialization structure, no. >> >> I meant that YAML has some flexibility in syntax, which probably should >> be exploited by the instance writer to improve readability. >> >> For that you'd need a sufficiently adjustable pretty-printer, but that >> also means that you can't reuse ToJSON. >> >> Roman >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > >

1 0

Re: Proposal: Add isLeft/isRight to Data.Either
by Gabriel Gonzalez 06 Dec '12

06 Dec '12

Although I provide "isLeft" and "isRight" in my "errors" package, count me against adding them to Data.Either. I only include them in "errors" because it is supposed to be a "everything and the kitchen sink" utility library. The API of standard libraries should provide guidance to new users for how to program idiomatically in Haskell and including those two functions will very likely lead new users astray from pattern matching, giving them a poor initial impression of Haskell.

1 0

Proposal: Add Functor instances for ArgOrder, OptDescr and ArgDescr
by Bas van Dijk 04 Dec '12

04 Dec '12

Hello, I recently needed Functor instances for the types in System.Console.GetOpt. Note that the test-framework package also defines[1] these instances. Discussion deadline: 1 week (I assume this is a no-brainer). Regards, Bas [1] http://hackage.haskell.org/packages/archive/test-framework/0.6.1/doc/html/s…

4 4

Proposal: Add (&) to Data.Function
by Yitzchak Gale 01 Dec '12

01 Dec '12

It is a common idiom to write a sequence of composed combinators in reverse order to the way they would be written with ($) or (.). That naturally expresses the idea of the combinators as operations being applied in the given order. This comes up so often, and is commonly used so many times in a single expression, that Control.Arrow.>>> is far too wordy, and even a two- character operator is awkward. Surprisingly, until recently the operator (&) was still not used in any of the popular libraries, and its name naturally expresses the idea we are looking for. This operator has now been defined in the lens package. We hereby propose to move it to its natural home for more general use, Data.Function. As in the lens package, we define the operator as a flipped version of ($), but with slightly higher precedence for better interaction with ($), and with left associativity. This definition has already proven useful and convenient even in the presence of the large and varied corpus of combinators and operators in the lens package. (There it was formerly known as (%), but that clashed with the usual meaning of (%) from Data.Ratio.) infixl 1 & (&) :: a -> (a -> b) -> b a & f = f a {-# INLINE (&) #-} Discussion period: 2 weeks http://hackage.haskell.org/trac/ghc/ticket/7434 Thanks, Yitz

29 67