February 2015 - Libraries

Proposal: Functor and friends for the wrappers in Data.Monoid
by Oleg Grenrus 24 Feb '15

24 Feb '15

I propose to add Functor, Applicative, Monad, Foldable, and Traversable and maybe even MonadFix instances to wrapper newtypes in the Data.Monoid module. The same way as in the semigroups package, e.g. https://hackage.haskell.org/package/semigroups-0.16.1/docs/Data-Semigroup.h… <https://hackage.haskell.org/package/semigroups-0.16.1/docs/Data-Semigroup.h…> Basically: instance Functor Sum where fmap f (Sum x) = Sum (f x) instance Foldable Sum where foldMap f (Sum a) = f a instance Traversable Sum where traverse f (Sum a) = Sum <$> f a instance Applicative Sum where pure = Sum a <* _ = a _ *> a = a Sum f <*> Sum x = Sum (f x) instance Monad Sum where return = Sum _ >> a = a Sum a >>= f = f a instance MonadFix Sum where mfix f = fix (f . getSum)

11 23

GHC 7.10 will use Plan FTP
by Simon Peyton Jones 23 Feb '15

23 Feb '15

Colleagues You will remember (see this email<https://mail.haskell.org/pipermail/libraries/2015-February/024925.html>) that the Haskell community has been engaged in a debate about proposed changes to the Haskell Prelude, the Plan-List or Plan-FTP debate<https://ghc.haskell.org/trac/ghc/wiki/Prelude710>. We decided to hold an open survey to get feedback from the community. Simon Marlow and Simon PJ were asked to make a decision in the light of that feedback. The survey closed on 21 Feb, so it's time to decide. Bottom line: we recommend Plan FTP. There are strong arguments in both directions. For the record, our own personal instincts were both in the conservative, Plan List direction. But the survey gave some pretty compelling feedback, and was far more unequivocal than we expected. Some details * Over 800 people participated in the survey. That's a lot for an 11-day window. Many wrote several paragraphs of supporting information. Thank you for participating so actively! * Overall, 82% of respondents were in favour of FTP, a 4:1 majority. Simon and I found this level of unanimity quite surprising - and it made our task much easier. We clearly under-estimated the Haskell community's appetite for absorbing change when they approve of the direction of travel. * Herbert helped us by doing a rough categorisation into hobbyist/non-hobbyist responses. o The first interesting fact is that there were a lot of non-hobbyist responses: in fact a majority (58%) of the responses were from non-hobbyists. So increasingly people are using Haskell for real work. o The support for Plan FTP among hobbyists was overwhelming (over 87%). But it was still very strong indeed among non-hobbyists (over 79%). Caveat: time was short, so the hobby/non-hobby categorisation is extremely approximate. But since the results are so unambiguous, even the crude results are helpful. * We tried filtering out responses that were blank in the name field and both text boxes. The 82% majority did not budge. What happens now * GHC 7.10 will embody Plan FTP. * The Core Libraries committee, freshly energised and informed by this episode, is drafting new guidelines to clarify what it does, and how it works; and to help avoid a repetition of the recent drama. * The responses. In the survey we said "We won't publish either textual responses or personally-identifying information without your consent. The full responses will be made available only to a limited few." However, the English-language comments are a remarkable snapshot of the Haskell community, and it would be a shame to discard them without deeper study. We propose to make them available to the Core Libraries Committee, to inform their future choices. If anyone else wants to digest the comments into a summary report, we think that would be a service to the community, and (in our view, provided they are a reputable person etc) would fall under the "available to a limited few" rubric. If that appeals to you, write to us. If you object even to such limited sharing, write to us too. This wasn't an entirely easy process, especially because it happened so late in the release cycle. But although many people felt quite strongly about List vs FTP, the whole debate has involved light rather than heat; people have concentrated on the technical issues, rather than yelling. Overall, it's been very encouraging to see the resilience, transparency, and constructive tone of the community. We really appreciate that - thank you. Simon Marlow and Simon Peyton Jones

1 0

openBinaryTempFile
by Ben Franksen 21 Feb '15

21 Feb '15

We are using this function from base in Darcs in a way that causes trouble: the returned file handle is closed immediately and only the filename is passed on. Then the file gets re-opened and closed again and some time later deleted. If openBinaryTempFile is used in this way a few times in a row, it returns the same file name every time. I tested this with a small test program. My question: is openBinaryTempFile supposed to behave like that (if used in this way)? I am testing this on an ubuntu trusty with ghc-7.6.3, meaning base-4.6.0.1. Has the function been changed in later versions? Cheers Ben -- "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." ― C.A.R. Hoare

2 3

Pattern match checking for GADTs
by Simon Peyton Jones 19 Feb '15

19 Feb '15

Friends George Karachalas, Tom Schrijvers, Dimitrios Vytiniotis, and I are working on finally cracking the problem of accurately reporting pattern-match overlap and redundancy warnings, in the presence of GADTs. You know the problem; consider vzip :: Vect n a -> Vect n b -> Vect n (a,b) vzip VN VN = VN vzip (VC x xs) (VC y ys) = VC (x,y) (vzip xs ys) data Vect :: Nat -> * -> * where VN :: Vect Zero a VC :: a -> Vect n a -> Vect (Succ n) a Are there any missing equations in vzip? No! But GHC complains anyway. We have lots of Trac tickets about this; e.g. https://ghc.haskell.org/trac/ghc/ticket/3927. We now have a draft paper (wait a week) and a prototype implementation, that fixes the problem. But we need your help. We'd like to try our prototype on real code, not just toy examples. So, could you send George a pointer to any packages you have, or know of, that * use GADTS (or other fancy type features) and * would benefit from accurate pattern-match overlap/redundancy warnings? Specifically: * Where you have had to add a catch-all f _ _ = error "impossible" to silence GHC from saying "missing patterns" * Or where you have added {-# OPTIONS_GHC -fno-warn-missing-patterns #-} to silence the warnings. * Or something else like that. George's email is in cc. Time is short - the ICFP deadline is on 27 Feb. So sooner is better than later for us. But later is better than never. Thank you! Simon

4 4

RE: Behavior change of Data.Char
by Simon Peyton Jones 19 Feb '15

19 Feb '15

It'd be good to document this condition/invariant in the Haddocks, wouldn't it?! Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Herbert Valerio Riedel | Sent: 19 February 2015 10:42 | To: Kazu Yamamoto | Cc: libraries(a)haskell.org; ghc-devs(a)haskell.org | Subject: Re: Behavior change of Data.Char | | On 2015-02-19 at 06:19:18 +0100, Kazu Yamamoto (山本和彦) wrote: | > It seems to me that some characters of GHC 7.10.1RC2 behave | > differently from those of GHC 7.8.4: | > | > 7.8.4 7.10.1RC2 | > isLower (char 170) True False | | Fwiw, the motivation for that particular change may be (I'm just | guessing here) to have the following condition hold: | | \c -> isLower c `implies` (not . isLower . toUpper) c | | i.e. if something is 'lower-case', then applying 'toUpper' should | result in a character that is not 'lower-case' anymore. This didn't | hold with 7.8.4's Unicode 6, but now holds with 7.10.1's Unicode 7 | definitions. | | Cheers, | hvr | _______________________________________________ | ghc-devs mailing list | ghc-devs(a)haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

Behavior change of Data.Char
by Kazu Yamamoto 19 Feb '15

19 Feb '15

Hi, It seems to me that some characters of GHC 7.10.1RC2 behave differently from those of GHC 7.8.4: 7.8.4 7.10.1RC2 isLower (char 170) True False isSymbol (chr 182) True False isPunctuation (chr 182) Fase True Is this intentional? I noticed this because I received a bug report: https://github.com/kazu-yamamoto/word8/issues/3 As you can see, 167 also behaves differently. --Kazu

3 3

Re: Seeking an active maintainer for 'directory'
by Edward Kmett 18 Feb '15

18 Feb '15

And we have a winner. Thanks, Phil. If you need any help from the core libraries committee, just ask; we'll support your efforts however we can. -Edward On Tue, Feb 17, 2015 at 2:25 PM, Phil Ruffwind <rf(a)rufflewind.com> wrote: > > Is anybody interested in nominating themselves for this role? > > I would be interested in this. I'm generally quite meticulous :) and > I'm familiar with the APIs of both POSIX and Win32, albeit more so > with POSIX. > > -- > Phil >

3 4

Overloadable list type notation
by Greg Weber 17 Feb '15

17 Feb '15

I had an idea whose goal is to ease people into Foldable, Traversable, etc. There could be a notation that shows the generalization that is occurring. map :: Functor [_] => (a -> b) -> [a] -> [b] This means that the syntax for the list type is now syntax for the variable created by the Functor constraint. Adding such a thing to the language is probably not a good idea, but someone might possibly like such a notation for pedagogy. Of course, it will be pointed out that a Functor is not just a container. But Foldable is sometimes expressed as "anything that toList can be called on", so it should make sense there. Greg Weber

6 10

Seeking an active maintainer for 'directory'
by Edward Kmett 17 Feb '15

17 Feb '15

The 'directory' package could use an active maintainer. Currently, the package falls to the Core Libraries Committee for maintenance, but we've had a number of issues accrete for the directory package over the last six months or so, which need some attention to detail and a good understanding of cross-platform issues. Is anybody interested in nominating themselves for this role? -Edward

1 0

Re: [Haskell-cafe] A Proposed Law for Foldable?
by Edward Kmett 13 Feb '15

13 Feb '15

There are 3 cases ruled out by this law. Two of them I'd have no trouble seeing go, the third one I think damages it beyond repair. First, `foldMap = mempty` is currently an admissable definition of foldMap for anything that is not Traversable. The law effectively talks backwards and ensures that you have to give back info on every 'a' in the container, so this is ruled out for any container that actually 'contains' an a. I'm pretty much okay with that case being ruled out. Second, There are instances such as the Foldable instance for `Machine` in the machines package. Here it starves the machine for input and takes the output and folds over it. However, these are not 'all of the 'a's it is possible to generate with such a machine, as you can construct a function (Machine ((->) b) a -> Maybe a) that feeds the machine a 'b' and then gets out an 'a' that would not occur in toList. One could argue that this Foldable violates the spirit of Foldable. I'm somewhat less okay with that case being ruled out as folks have found it useful, but I could accept it. Third, In the presence of GADTs, the fact that Foldable only accepts 'f' in negative position means that 'f' might be a GADT, telling us more about `a`, despite your function being parametric. e.g. it could carry around a Num constraint on its argument. Extracting this dictionary from the GADT would enable sum :: Num a => f a -> a to be used in your function (forall a. f a -> Maybe a), preventing parametricity from providing the insurance you seek. This means that your law would rule out any `Foldable` that exploits GADT-like properties. A version of `Set` where the data type carries around the `Ord` instance internally, could for instance instantiate `elem` in log time. That example becomes only marginally safe under your law because of `min` and `max` being in Ord and producing "new" a's, but it also rules out similar O(1) optimizations for sum or product in other potential containers, which could carry Num. These I'm much more reluctant to let go. You might be able to repair your law by also quantifying over `f` with a Foldable constraint or some such, but that re-admits the former 2 laws and seems to make it vacuous. -Edward On Thu, Feb 12, 2015 at 2:59 PM, Atze van der Ploeg <atzeus(a)gmail.com> wrote: > Hi Gershom! > > Do you have an example where this law allows us to conclude something > interesting we otherwise would not have been able to conclude? > > Cheers, > > Atze > On Feb 12, 2015 8:47 PM, "Gershom B" <gershomb(a)gmail.com> wrote: > >> For a long time, many people, including me, have said that "Foldable has >> no laws" (or Foldable only has free laws) -- this is true, as it stands, >> with the exception that Foldable has a non-free law in interaction with >> Traversable (namely that it act as a proper specialization of Traversable >> methods). However, I believe that there is a good law we can give for >> Foldable. >> >> I earlier explored this in a paper presented at IFL 2014 but (rightfully) >> rejected from the IFL post-proceedings. ( >> http://gbaz.github.io/slides/buildable2014.pdf) That paper got part of >> the way there, but I believe now have a better approach on the question of >> a Foldable law -- as sketched below. >> >> I think I now (unlike in the paper) can state a succinct law for Foldable >> that has desired properties: 1) It is not "free" -- it can be violated, and >> thus stating it adds semantic content. 2) We typically expect it to be >> true. 3) There are no places where I can see an argument for violating it. >> >> If it pans out, I intend to pursue this and write it up more formally, >> but given the current FTP discussion I thought it was worth documenting >> this earlier rather than later. For simplicity, I will state this property >> in terms of `toList` although that does not properly capture the infinite >> cases. Apologies for what may be nonstandard notation. >> >> Here is the law I think we should discuss requiring: >> >> * * * >> Given Foldable f, then >> forall (g :: forall a. f a -> Maybe a), (x :: f a). case g x of Just a >> --> a `elem` toList x >> * * * >> >> Since we do not require `a` to be of type `Eq`, note that the `elem` >> function given here is not internal to Haskell, but in the metalogic. >> >> Furthermore, note that the use of parametricity here lets us make an "end >> run" around the usual problem of giving laws to Foldable -- rather than >> providing an interaction with another class, we provide a claim about _all_ >> functions of a particular type. >> >> Also note that the functions `g` we intend to quantify over are functions >> that _can be written_ -- so we can respect the property of data structures >> to abstract over information. Consider >> >> data Funny a = Funny {hidden :: a, public :: [a]} >> >> instance Foldable Funny where >> foldMap f x = foldMap f (public x) >> >> Now, if it is truly impossible to ever "see" hidden (i.e. it is not >> exported, or only exported through a semantics-breaking "Internal" module), >> then the Foldable instance is legitimate. Otherwise, the Foldable instance >> is illegitimate by the law given above. >> >> I would suggest the law given is "morally" the right thing for Foldable >> -- a Foldable instance for `f` should suggest that it gives us "all the as >> in any `f a`", and so it is, in some particular restricted sense, initial >> among functions that extract as. >> >> I do not suggest we add this law right away. However, I would like to >> suggest considering it, and I believe it (or a cleaned-up variant) would >> help us to see Foldable as a more legitimately lawful class that not only >> provides conveniences but can be used to aid reasoning. >> >> Relating this to adjointness, as I do in the IFL preprint, remains future >> work. >> >> Cheers, >> Gershom >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

4 7