- Libraries - Haskell.org

None
by Anthony Clayden 10 Apr '17

10 Apr '17

> On Sun Apr 9 19:24:12 UTC 2017, Sven Panne wrote: >> 2017-04-09 2:01 GMT+02:00 Ben Franksen : >>> Am 08.04.2017 um 04:03 schrieb Anthony Clayden: >>> [...] So to take your examples from an earlier thread, >>> what do you expect Haskell to do here?: >>> >>> maximum (True,2) => ? >>> minimum ((3, 4),5) => ? -- i.e. :: ((Int, Int), Int) >>> sum (7,3.14) => ? -- i.e. :: (Int, Double) >>> product (Left $ error "Errk") => ? -- i.e. :: >>> Either e Int >> >> I (and others) think these should be type errors. >> > Exactly. OK. Do y'all think there should be a `toList` method for them? Indeed, should there be a `toList` method available for any data type that doesn't implement `fromList`? Perhaps `toList` should not be a method of Foldable? > >>> Do you expect Foldable (a, a) to behave differently >>> vs Foldable (b, a) vs Foldable ((a, a), a) vs ...? >>> >> It would be nice if we could all agree on removing these instances. >> > Yep. :-) >> BTW, I find it remarkable that of those who defend these instances, few >> seem to be especially interested in clarifying the OP's question: what >> laws exactly do we expect for Foldable? [...] >> One of the Laws appears to be that `length` etc behave as `length . toList`. AntC

1 0

Giving up boxes package
by David Feuer 10 Apr '17

10 Apr '17

I've been way too busy with GHC and containers to have time to devote to boxes. If anyone wants to take over, they are welcome. The main priority right now is improving documentation, but someone also needs to make sure it works with 8.2 as soon as its dependencies do.

1 0

Re: Constraints on definition of `length` should be strengthened
by Anthony Clayden 10 Apr '17

10 Apr '17

> On Tue Apr 4 06:50:55 UTC 2017, Sven Panne wrote: >> 2017-04-04 8:15 GMT+02:00 Vladislav Zavialov: >>> Tuples are unbiased cartesian products, full stop. >> >> This statement is not correct. > According to probably all the math books in the world, > the statement is correct, > at least if we want to see tuples as cartesian products. .. Sven, I have a lot of sympathy with the digruntlement about Foldable `length` over tuples. But if you're going to start appealing to math, you'd better get your math correct. Whether or not tuples are unbiased, even wikipedia will tell you they're not commutative. So to take your examples from an earlier thread, what do you expect Haskell to do here?: maximum (True,2) => ? minimum ((3, 4),5) => ? -- i.e. :: ((Int, Int), Int) sum (7,3.14) => ? -- i.e. :: (Int, Double) product (Left $ error "Errk") => ? -- i.e. :: Either e Int Do you expect Foldable (a, a) to behave differently vs Foldable (b, a) vs Foldable ((a, a), a) vs ...? Let's get everybody agreed on that. Then we can talk about our currying/kind system. Note that there's been an `instance Foldable Maybe` for ever, and `toList` applied to that returns a 0-or-1 length list. >> Look at their kind: >> >> > :k (,) >> > (,) :: * -> * -> * >> >> The same currying business is going on here. [...] > That's an artifact of our kind system, > not a consequence of the usual definition of cartesian products. AntC

4 3

Constraints on definition of `length` should be strengthened
by Paolo Giarrusso 10 Apr '17

10 Apr '17

TL;DR. One (implicit?) assumption in recent debates on `length` seems to be unfounded, because current docs for Foldable are meant to be much stronger than their actual language, unless I'm missing something. Clarifications welcome. If my understanding is right, I'd suggest somebody fixes the docs. One point is not clear to me, so at present I could not volunteer to fix them myself. In recent debates, it was assumed or implied that `length` must be equivalent to length = length . toList > we also have a kind > system, so we can ignore the name. > length :: f a -> Int > We immediately know that values of the kind (* -> *) slot in to the > value (f), with a kind checker to ensure we get it correct. Therefore, > we can easily reason about the length of values of kind ((,) a) I don't quite get how that argument is supposed to proceed. However that's meant, that seems incorrect because length is a typeclass method, so even the following strawman instance typechecks: instance Foldable ((,,) a b) where length _ = 42 I assume this should violate some law, but the relevant law seems to be forgotten. The most constraining language I can find is the following: > sum, product, maximum, and minimum should all be essentially equivalent to foldMap forms, such as > sum = getSum . foldMap Sum > but may be less defined. but (a) `length` is not even mentioned, even if it's intended (b) I think those should be laws (c) using "should" and "essentially" in "should all be essentially equivalent", seems too weak. I can infer the intention, but this seems insufficient to declare Docs for `length` don't help either: > Returns the size/length of a finite structure as an Int. The default implementation is optimized for structures that are similar to cons-lists, because there is no general way to do better. I mean, these docs use the English word "length", so that actually forbids 42, but that text is too vague to forbid 3 frankly. As I missing something? I also take issue with "may be less defined", and here I'm not sure of the intention, since that declares instance Foldable ((,,) a b) where length _ = undefined as legal. I imagine the point is about taking the length of partially undefined structures, but it's not clear to me why a custom `sum` implementation would be less defined than `sum = getSum . foldMap Sum`. Even ignoring the above instances (which I would never write down), I can't reason much about my code based on those specifications. This situation seems unfortunate. Cheers, -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/

14 37

Re: Constraints on definition of `length` should be strengthened
by dominic＠steinitz.org 10 Apr '17

10 Apr '17

I am not sure what to make of the “documentation” to which you refer. For example, a type Tensor seems to be defined. Now you can tensor lots of things with some algebraic structure but most commonly vector fields and modules (modules in the mathematical sense that is). The type Tensor seems to have no relation to these and there is no prose giving an indication of the author’s intent. Perhaps we should be cautious about adducing other parts of the package as evidence? > Already done mate. > > https://hackage.haskell.org/package/hask-0/docs/Hask-Category.html#t:Either > https://hackage.haskell.org/package/hask-0/docs/Hask-Category.html#t:Functor > > Note the multiple Functor instances for Either and Coproduct. e.g. > > - Functor * (* -> *) Either > - Functor * * (Either a) > etc etc > > On 09/04/17 10:29, Henrik Nilsson wrote: >> And of course, if, in a hypothetical future version of Haskell >> where we could make all possible functor instances for tuples, >> the question becomes: which one do we pick? The answer might well >> be "none" (in the prelude, at least). Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

2 1

Re: Constraints on definition of `length` should be strengthened
by Anthony Clayden 07 Apr '17

07 Apr '17

> On Wed Apr 5 16:15:48 UTC 2017, Paolo Giarrusso wrote: > Thanks for all the mails, but I'm still missing an answer, > so I must have done something wrong. :-) Thanks Paolo, you've done nothing wrong IMHO. You've done the community a service by pointing out an omission in the docos. It's the same failure to communicate clearly that's given rise to the whole FTP kerfuffle. > I guess I didn't explain my question well. > Or nobody thinks it's worth answering (in which case, sorry, but I'd > prefer to be told I'm misguided, over having the question ignored). I think your original question was clear. I think it is very well worth answering. That is: answering what are the 'Laws' for Foldable? I've been waiting patiently for Libraries HQ to: * explain the applicable Laws * acknowledge they're not doco'd * volunteer to fix that > ... I'm really asking a different question: do length docs actually > give a complete specificationit still seems to me they don't. I agree they don't. > ... > But that's very confusing: can really debate on `length (a, b) = 1` > have continued for so long, without noticing that `length = getSum . > foldMap (Sum . const 1)` is a fundamental assumption and is not > mandated by anything written down? I assume I must be missing > something, which is why I asked. The only reply I've seen [from David F, you copied below, apologies if I've missed others] doesn't give any "fundamental assumption". It only says "should be quite well-behaved" and "pretty much everybody agrees on". I'm not 'getting at' David, at least he answered. I agree with your intuition that Foldable length = length . toList But that just pushes the question back to what are the Laws for `toList`? Note that `toList` has been in Foldable 'for ever'. And instance Foldable Maybe 'for ever'. That returns a 0-or-1 length list. Contrast that `instance Foldable ((,) b)` appeared in GHC 7.8 ~2014, along with `instance Foldable Either`. > Of all incomplete docs, this matters more > since `length (a, b)` is so surprising. I'd say the surprising bit is `toList (a, b)`. `length` is just a consequence. Cue another long thread on `toList`. I'm inclined to agree with Edward K, that there's only one possible definition for `toList` -- that is, if we accept `instance Foldable ((,) b). Cue another long thread on tuple instances, and the Either instance. > The unsuspecting looking at docs lacks the facts needed to > infer this wart. Spelling out implications would IMHO be even better, > for the same reason people state theorems even though they can be > proved, but maybe some disagree. A complete spec would be a starting > point. Yes. In particular, the conspicuous lack of docos is now wildly at variance with all the tutorial/intro texts, which explain `length` as for Lists. I plain think that `length` should be Lists-only; there should be some other name for Foldable's size. >>> On 3 April 2017 at 17:59, David Feuer wrote: >>> length should be quite well-behaved relative to foldMap: >>> >>> length = getSum . foldMap (Sum . const 1) >> Thanks, that looks useful to add to docs. I was thinking of `length = >> length . toList`. >>> Another law pretty much everyone agrees on is that *if* f is an instance of >>> Traversable, then >>> >>> foldMap = foldMapDefault AntC

2 1

Package maintainership takeover: quickcheck-instances
by Oleg Grenrus 07 Apr '17

07 Apr '17

The quickcheck-instances provides QuickCheck type-classes' instances for Haskell Platform packages. Unfortunately, author and current maintainer Antoine Latter is quite unresponsive. There is handful of PR open [2], and I had to use Hackage Trustee powers to allow new versions of dependencies (to keep e.g. Stackage nightly going on). I have tried to contact him to offer a co-maintainership help (at 14.12.2016). Cheers, Oleg Grenrus - [1]: http://hackage.haskell.org/package/quickcheck-instances - [2]: https://github.com/aslatter/qc-instances/pulls

1 0

Civility notes (was "Traversable instances for (,,) a b")
by Tom Murphy 06 Apr '17

06 Apr '17

Hi Fumiaki! I agree with you that some poorly-chosen words by a few people have soured this conversation, but please don't let that turn you completely off of the productive conversation most of us are attempting to have! I think it's largely been successful, too: even if many of us haven't changed our -1/+1 votes, I for one have had my ideas challenged and have a more nuanced view than before talking with everyone here. Henning and Edward are two examples (one from each side of the +1/-1 chasm) who have been aided by this discussion, in making important progress to finding a middle ground (each in the form of proposed compiler changes). To the rest of us: Fumiaki regretting having posted here is a pretty stark example of why speaking politely matters. People being scared away and feeling unwelcome is a real phenomenon, and we need to do our part to fix it. I'd propose: - If you haven't read it already, SPJ recently wrote a heartfelt letter on the subject [0]. We've gotten better since then, but clearly we're not finished. - Civility is a norm, and norms sometimes need to be enforced. From a distance, we all look bad (and unwelcoming!) if anyone is hostile and we don't make it clear it's not acceptable. Speak up! That said, everyone makes mistakes - try to give people space to apologize and move on. - If someone says something insulting to you, please take that as a sign to become more polite, not less so. The downward spiral is real. If you're called out for saying something regrettable (again, regardless of if you're +1 or -1 on this issue), *please* take our desire for civil conversation seriously. Responses like (I'm paraphrasing, and not trying to cite anyone specifically): "It was a joke (mostly)" and "It's your fault if you didn't get the joke" are worse than not writing anything at all. Ideal would be a quick "Sorry!" Thanks, all! Tom [0] https://mail.haskell.org/pipermail/haskell/2016-September/024995.html On Sun, Apr 2, 2017 at 12:11 PM, Fumiaki Kinoshita <fumiexcel(a)gmail.com> wrote: > The discussion has diverged to flaming due to a few offensive people. I > guess I shouldn't have posted a proposal here, I should have submitted a > patch instead. > > 2017-03-23 19:53 GMT+09:00 Fumiaki Kinoshita <fumiexcel(a)gmail.com>: > >> It's surprising that they are missing (forgive me, I'm not here to make >> people grumpy). >> > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >

16 20

Getting containers updated in Stackage
by David Feuer 03 Apr '17

03 Apr '17

It's come to my attention that Stackage doesn't have the latest and greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just released 0.5.10.2. It'd be nice to get that fixed, but the containers maintainers do not have the time to take responsibility for Stackage curation. Could whoever's responsible please take care of it? Thanks, David

5 7

Deriving length better: missing method problem
by David Feuer 02 Apr '17

02 Apr '17

GHC 8.4 DeriveFoldable will derive the definition of `null` rather than falling back on the default. This can produce dramatic performance improvements. I would like to do the same for `length`, but unfortunately, there's a problem. ### Why I want to derive length Consider the declaration data Foo a = Foo (Map "String" a) (Set a) A hand-written definition of `length` would look like this: length (Foo m set) = length m + length set This would produce an O(1) implementation of length, since Map and Set are annotated with their lengths. But the default implementation of length (which is what you get when you use `deriving Foldable`) would instead produce length foo = foldl' (\acc _ -> acc + 1) 0 foo which is O(n). Gross. ### What's the problem? There's no problem deriving length for Foo. The trouble comes when trying to derive length for a recursive type. data List a = Nil | Cons a (List a) The most obvious implementation to derive would be length Nil = 0 length (Cons _ xs) = 1 + length xs but this is not tail recursive! That's absolutely no good. What we *want* here is length = lengthPlus 0 lengthPlus acc Nil = acc lengthPlus !acc (Cons _ xs) = lengthPlus (acc + 1) xs We actually could arrange for that in this case, since we see that a `List` contains itself recursively. But what about *mutual* recursion? data List2 a = Nil | Cons a (List2' a) newtype List2' a = List2' (List2 a) Now the deriving mechanism can't see the recursion, and everything is horrible. ### The simplest solution It seems likely that the simplest solution would be what nobody really wants: add yet another method to Foldable: lengthPlus :: Int -> f a -> Int lengthPlus n xs = n + length xs We could derive efficient implementations of `lengthPlus` without any particular difficulty. ### Alternatives? I haven't thought of any plausible alternatives yet. Maybe someone else will. David

1 0