- Libraries - Haskell.org

Proposal: Add isLeft/isRight to Data.Either
by Simon Hengel 14 Dec '12

14 Dec '12

Hi, I propose to add isLeft/isRight to Data.Either, with the obvious definitions: isLeft :: Either a b -> Bool isLeft (Left _) = True isLeft (Right _) = False isRight :: Either a b -> Bool isRight (Left _) = False isRight (Right _) = True There has been a discussion on that before [1]. While I agree that fromLeft/fromRight are moot, I don't see issues with isLeft/isRight. Personally I care mostly about isLeft, but for orthogonality I propose to add both isLeft and isRight. Here is a (possibly incomplete) list of packages that come with their own definition of isLeft: snap-core, multifocal, PriorityChansConverger, tamarin-prover-utils, Agda, PCLT, cmdtheline, scyther-proof, xmlhtml, hspec-expectations, Glob, language-glsl, Craft3e, hledger-lib, narc, nemesis, type-settheory, PCLT-DB, RJson, bio, errors, rss2irc, heist Discussion period: 2 Weeks Cheers, Simon [1] http://www.haskell.org/pipermail/libraries/2006-October/006098.html

18 35

digamma function
by Ben Gamari 14 Dec '12

14 Dec '12

My digamma package[1] implements an approximation to the digamma function (due to Tom Minka). Considering that the math-functions package already has a gamma implementation, it seems it would be natural to merge digamma into this package. Alternatively (or additionally), James Cook's gamma package also has a variety of gamma implementations and is also a candidate for merging digamma into. I don't mind maintaining digamma, but it might be easier for others if there were a single package providing all of these functions. Do others have an opinion on this? Are either (or both) of you interested in picking up a digamma implementation? Cheers, - Ben [1] http://hackage.haskell.org/package/digamma

3 2

The PVP ought to mention dependency bounds (Was: Growing Haskell Platform)
by Johan Tibell 11 Dec '12

11 Dec '12

On Thu, Dec 6, 2012 at 11:52 PM, Michael Snoyman <michael(a)snoyman.com> wrote: > I thought the natural response to this would be to put a lower bound on > text. After all, following the PVP, there should be no problem with updating > a minor version number. However, when I did so, many users of the Haskell > Platform were no longer able to compile due to conflicting dependencies. The > result: I had to put in some dirty conditional compilation tricks in > persistent to avoid inlining `pack` when using older versions of text. I've meant to write about this but haven't yet found time to do so. Assuming that the goal of the PVP is to make sure that a packages that previously compiled continues to compile, dependencies must be taken into account when computing package version number bumps. For example, given these packages: A-1.0 B-1.0 depends on A-1.0.0.* C-1.0 depends on A-1.0.0.* and B-1.0.0.* Now assume that A-2.0 is released and B starts depending on the new version of A (without changing its own API). He now have this situation: A-1.0 A-2.0 B-1.?.?.? depends on A-2.0.0.* C-1.0 depends on A-1.0.0.* and B-1.0.0.* If B only bumps its patch-level version (i.e. to B-1.0.0.1), C no longer compiles (due to a version constraint failure) with B-1.0.0.1 even though C's dependency on B (i.e. B-1.0.0.*) suggests that it would. If B updates it's lower bound on a dependency it must bump its own major version number. We can summarize this under the slogan "versions are APIs"; the versions you depend on are part of your API. Aside: Even if cabal install would backtrack and *not* use the new version of B (i.e. B-1.0.0.1) and thus be able to compile C-1.0 using the old version of B things would still be bad as C's dependency constraints would be a lie. I think the PVP policy must be changed to require that increasing lower bounds on dependencies requires an increase in the major version number. -- Johan

8 15

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 11 Dec '12

11 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