- Libraries - Haskell.org

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Gregory Collins 18 Oct '15

18 Oct '15

On Mon, Oct 5, 2015 at 3:18 PM, Bryan Richter <b(a)chreekat.net> wrote: > Hang on a moment, are you saying that all the people writing to argue > that these changes would require them to write dozens more #ifdef's > actually don't have to write any at all? > Um, no, it usually isn't anything like that. Here's a sampling of some of the things I've used CPP for in the past few years: - After GHC 7.4, when using a newtype in FFI imports you need to import the constructor, i.e. "import Foreign.C.Types(CInt(..))" --- afaik CPP is the only way to shut up warnings everywhere - defaultTimeLocale moved from System.Locale to Data.Time.Format in time-1.5 (no compat package for this, afaik) - one of many various changes to Typeable in the GHC 7.* series (deriving works better now, mkTyCon vs mkTyCon3, etc) - Do I have to hide "catch" from Prelude, or not? It got moved, and "hiding" gives an error if the symbol you're trying to hide is missing. Time to break out the CPP (and curse myself for not just using the qualified import in the first place) - Do I get monoid functions from Prelude or from Data.Monoid? Same w/ Applicative, Foldable, Word. I don't know where anything is supposed to live anymore, or which sequence of imports will shut up spurious warnings on all four versions of GHC I support, so the lowest-friction fix is: break out the #ifdef spackle - ==# and friends return Int# instead of Bool after GHC 7.8.1 - To use functions like "tryReadMVar", "unsafeShiftR", and "atomicModifyIORef'" that are in recent base versions but not older ones (this is a place where CPP use is actually justified) -- Gregory Collins <greg(a)gregorycollins.net>

6 7

Default definition for fromRational
by Joe Hermaszewski 15 Oct '15

15 Oct '15

A suitable default definition for fromRational could be the following: fromRational n = fromInteger (numerator n) / fromInteger (denominator n) Changing the MINIMUM pragma to just {-# MINIMAL recip | (/) #-} - Joe

2 1

Final Call for Haskell Prime language committee Nominations!
by Herbert Valerio Riedel 11 Oct '15

11 Oct '15

The submission deadline (Wed, Oct 14 23:59:59 UTC 2015) for Haskell Prime self-nominations (see also original CfN at [1]) is near! If you have already submitted a self-nomination, please make sure (if it was sent to the haskell-prime list) that it shows up in the mailing list archives at - https://mail.haskell.org/pipermail/haskell-prime/2015-September/ or - https://mail.haskell.org/pipermail/haskell-prime/2015-October/ or (if you have only sent it to me directly) that I acknowledged receiving your submission by an email reply. Regards, Herbert Valerio Riedel [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html

1 0

Re: MRP, 3-year-support-window, and the non-requirement of CPP
by Herbert Valerio Riedel 11 Oct '15

11 Oct '15

On 2015-10-06 at 10:10:01 +0200, Johan Tibell wrote: [...] >> You say that you stick to the 3-major-ghc-release support-window >> convention for your libraries. This is good, because then you don't need >> any CPP at all! Here's why: >> >> [...] >> > > So what do I have to write today to have my Monad instances be: > > * Warning free - Warnings are useful. Turning them off or having spurious > warnings both contribute to bugs. Depends on the warnings. Some warnings are more of an advisory kind (hlint-ish). I wouldn't consider redundant imports a source of bugs. Leaving off a top-level signature shouldn't be a source of correctness bugs either. Also, warnings about upcoming changes (i.e. deprecation warnings) also are not necessarily a bug, but rather a way to raise awareness of API changes. At the other end of the spectrum are more serious warnings I'd almost consider errors, such as failing to define a non-defaulting method or violating a MINIMAL pragma specification, as that can lead to bottoms either in the form of runtime errors or even worse, hanging computations (in case of cyclic definitions). IMO, GHC should classify its warnings into severities/categories or introduce some compromise between -Wall and not-Wall. > * Use imports that either are qualified or have explicit import lists - > Unqualified imports makes code more likely to break when dependencies add > exports. > * Don't use CPP. That being said, as how to write your Monad instances today with GHC 7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This *does* work (admittedly for an easy example, but this can be generalised): --8<---------------cut here---------------start------------->8--- module MyMaybe where import Control.Applicative (Applicative(..)) import Prelude (Functor(..), Monad(..), (.)) -- or alternatively: `import qualified Prelude as P` data Maybe' a = Nothing' | Just' a instance Functor Maybe' where fmap f (Just' v) = Just' (f v) fmap _ Nothing' = Nothing' instance Applicative Maybe' where pure = Just' f1 <*> f2 = f1 >>= \v1 -> f2 >>= (pure . v1) instance Monad Maybe' where Nothing' >>= _ = Nothing' Just' x >>= f = f x return = pure -- "deprecated" since GHC 7.10 --8<---------------cut here---------------end--------------->8--- This example above compiles -Wall-clean and satisfies all your 3 stated requirements afaics. I do admit this probably not what you had in mind. But to be consistent, if you want to avoid unqualified imports at all costs in order to have full control of what gets imported into your namespace, you shouldn't tolerate an implicit unqualified wildcard `Prelude` import either. As `Prelude` can, even if seldom, gain new exports as well (or even loose them -- `interact` *could* be a candidate for removal at some point). > Neither AMP or MRP includes a recipe for this in their proposal. That's because -Wall-hygiene (w/o opting out of harmless) warnings across multiple GHC versions is not considered a show-stopper. In the specific case of MRP, I can offer you a Wall-perfect transition scheme by either using `ghc-options: -fno-mrp-warnings` in your cabal-file, or if that doesn't satisfy you, we can delay phase1 (i.e. redundant return-def warnings) to GHC 8.2: Now you can continue to write `return = pure` w/o GHC warning bothering you until GHC 8.2, at which point the 3-year-window will reach to GHC 7.10. Then starting with GHC 8.2 you can drop the `return` definition, and keep your More generally though, we need more language-features and/or modifications to the way GHC triggers warnings to make such refactorings/changes to the libraries -Wall-perfect as well. Beyond what Ben already suggested in another post, there was also the more general suggestion to implicitly suppress warnings when you explicitly name an import. E.g. import Control.Applicative (Applicative(..)) would suppress the redundant-import warning for Applicative via Prelude, because we specifically requested Applicative, so we don't mind that Prelude re-exports the same symbol. > AMP got one post-facto on the Wiki. It turns out that the workaround > there didn't work (we tried it in Cabal and it conflicted with one of > the above requirements.) Yes, that unqualified `import Prelude`-last trick mentioned on the Wiki breaks down for more complex imports with (redundant) explicit import lists. However, the Maybe-example above works at the cost of a wordy Prelude-import, but it's more robust, as you pin down exactly which symbol you expect to get from each module. > The problem by discussions is that they are done between two groups with > quite a difference in experience. On one hand you have people like Bryan, > who have considerable contributions to the Haskell ecosystem and much > experience in large scale software development (e.g. from Facebook). On the > other hand you have people who don't. That's okay. We've all been at the > latter group at some point of our career. [...] At the risk of stating the obvious: I don't think it matters from which group a given argument comes from as its validity doesn't depend on the messenger. Neither does it matter whether an argument is repeated several times or stated only once. Also, every argument deserves to be considered regardless of its origin or frequency. -- hvr

13 24

[containers] Proposal: Change to the Data.Map Monoid
by Nick Partridge 10 Oct '15

10 Oct '15

Hi, Currently the Monoid instance for Data.Map is implemented using union/unions, which are left biased. On key collision, it discards values from the right hand side of `mappend` - https://github.com/ghc/packages-containers/blob/bae098fb0a3994bc2b0ec331300… If you compare this with the Monoid for Maybe, it's like we're defaulting to First as the monoid instance for maps. A more useful instance, however very much a breaking change, would be to make the instance depend on a Monoid (or better yet, a Semigroup) for the values in the map: instance Monoid v => Monoid (Map k v) where mappend = unionWith mappend This lets us build up maps with values in a useful Monoid, and mappend them with gusto. Thoughts? - Nick Partridge Discussion period: 2 weeks.

15 22

ANNOUNCE: unordered-graphs
by Ivan Lazar Miljenovic 10 Oct '15

10 Oct '15

I have a relatively hacked-together graph library that uses unordered-containers as a backend available if anyone finds it interesting/useful: http://hackage.haskell.org/package/unordered-graphs It's primarily developed just for my own needs and thus I'm not sure how much future work I'll be doing on it, but I'm willing to accept pull requests. This library was semi-experimental in that I also tried a few things out with it: * Polymorphic node type * Fixed auto-generated edge type: this is because (node,node, label) triples (ala fgl) do not provide sufficient information to be able to distinguish between multiple edges, etc. * Type parameter to determine whether the graph is directed or undirected. * Typeclass to allow you to determine the type/output of a a match (I didn't end up actually using this, as the one time I needed to do a match I found the extra polymorphism caused problems; it also isn't comprehensive as I didn't write all that many instances.) -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0

Re: status and future of haskell98 and haskell2010 packages
by Herbert Valerio Riedel 08 Oct '15

08 Oct '15

On 2015-10-08 at 00:08:43 +0200, Andrey Chudnov wrote: > My e-mail was rejected from libraries(a)haskell.org (the official > maintenance contact of the two packages in question), so I'm trying my > luck here instead. Hoping I can get some answers on the following > questions: > > 1. What is the status of `haskell2010` and `haskell98` packages? Are > they supported? Deprecated? In need of new maintainers? Short answer: with GHC 7.10 it is not possible anymore to implement a proper[1] `haskell98` or `haskell2010` package anymore. More details can be found at https://ghc.haskell.org/ticket/9590 > 2. Assuming the answer to the previous question is "alive and well", > are there any plans to release new versions of those for GHC 7.10 and > beyond? In order to be able to recover support for a `haskell2010` package in newer GHCs, GHC will need to be extended in some way. I can think of two different paths to pursue to accomplish this, depending on whether type(classes) need to be shared with `base` or not. Moreover, it wasn't clear how much actual demand there really is to have the recent GHCs support a legacy `haskell2010` mode. So if there's somebody interested in resuscitating a `haskell98`/`haskell2010` package, please tell us what your use-case is (to help understand whether type(class) sharing w/ `base` is essential or not -- it's *much* more easier to get this working w/o the typeclass sharing requirement, whereas the typeclass-sharing variant might not even be possible at all) Cheers, hvr [1]: I.e. with the requirement that all code written conforming to the respective Haskell Report will be compileable via e.g. ghc -XHaskell2010 -hide-all-packages -package haskell2010 -c *.hs (to some degree, this was already broken before GHC 7.10 due to the superclass-removal on `Num`, but with AMP this was broken beyond tolerance)

1 0

Proposal: pare down traversable
by David Feuer 08 Oct '15

08 Oct '15

Traversable currently has traverse, sequenceA, sequence, and mapM methods. sequence and mapM seem to be dinosaurs now. I'd like to suggest that sequenceA be turned into a deprecated function and mapM be moved from Control.Monad to Data.Traversable and re-exported from Control.Monad. I expect most instance declarations to survive unchanged. The only CPP pain point will be that instances that define sequenceA will have to define sequence instead.

5 7

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Brandon Allbery 08 Oct '15

08 Oct '15

On Wed, Oct 7, 2015 at 4:54 PM, Bardur Arantsson <spam(a)scientician.net> wrote: > Please consider that the the way practical development really happens[2] ...among web developers, who of course are the only real developers? Have you considered that there are developers who are not web developers? The past day has convinced me that the web devs have relegated everyone else to fake-non-programmer status and actively want them out of the community because fake programmers don't benefit you real programmers. I had heard that the financial users generally refused to have anything to do with the Haskell community. Now I know why. I wonder how many of them, if any indeed are left after past breaking changes, are in the process of switching to OCaml. I'm sure you consider that a good thing, because they're obviously just holding back "real programmers". -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

3 2

Re: MRP, 3-year-support-window, and the non-requirement of CPP (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)
by Johan Tibell 07 Oct '15

07 Oct '15

(Resending with smaller recipient list to avoid getting stuck in the moderator queue.) On Tue, Oct 6, 2015 at 9:10 AM, Herbert Valerio Riedel <hvr(a)gnu.org> wrote: > On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote: > > On the libraries I maintain and have a copy of on my computer right now: > 329 > > > Although this was already pointed out to you in a response to a Tweet of > yours, I'd like to expand on this here to clarify: > > > You say that you stick to the 3-major-ghc-release support-window > convention for your libraries. This is good, because then you don't need > any CPP at all! Here's why: > > [...] > So what do I have to write today to have my Monad instances be: * Warning free - Warnings are useful. Turning them off or having spurious warnings both contribute to bugs. * Use imports that either are qualified or have explicit import lists - Unqualified imports makes code more likely to break when dependencies add exports. * Don't use CPP. Neither AMP or MRP includes a recipe for this in their proposal. AMP got one post-facto on the Wiki. It turns out that the workaround there didn't work (we tried it in Cabal and it conflicted with one of the above requirements.) PS: I'm a bit disappointed you seem to dismiss this proposal right away > categorically without giving us a chance to address your > concerns. The proposal is not a rigid all-or-nothing thing that > can't be tweaked and revised. That's why we're having these > proposal-discussions in the first place (rather than doing blind > +1/-1 polls), so we can hear everyone out and try to maximise the > agreement (even if we will never reach 100% consensus on any > proposal). > > So please, keep on discussing! > The problem by discussions is that they are done between two groups with quite a difference in experience. On one hand you have people like Bryan, who have considerable contributions to the Haskell ecosystem and much experience in large scale software development (e.g. from Facebook). On the other hand you have people who don't. That's okay. We've all been at the latter group at some point of our career. What's frustrating is that people don't take a step bad and realize that they might be in the latter group and should perhaps listen to those in the former. This doesn't happen, instead we get lots of "C++ and Java so bad and we don't want to be like them." Haskell is not at risk of becoming C++ or Java (which are a large improvement compared to the languages came before them). We're at risk of missing our window of opportunity. I think that would be a shame, as I think Haskell is a step forward compared to those languages and I would like to see more software that used be written in Haskell. We've been through this many times before on the libraries list. I'm not going to win an argument on this mailing list. Between maintaining libraries you all use and managing a largish team at Google, I don't have much time for a discussion which approaches a hundred emails and is won by virtue of having lots of time to write emails. -- Johan

4 4