May 2016 - Libraries - Haskell.org

Re: TDNR without new operators or syntax changes
by Jeremy . 22 May '16

22 May '16

Yes, that it indeed was I meant. AntC seems to be replying to a much more complicated/invasive proposal than what I had intended, apologies if I wasn't clear. (I see in retrospect that I may have misunderstood the original TDNR proposal, understandably leading to confusion.) 1. If the compiler encounters a term f a, and there is more than one definition for f in scope (after following all of the usual rules for qualified imports); 2. And exactly one of these definitions matches the type of a (or the expected type of f if given); 3. Then this is the definition to use. That is all, although point 2 could be extended to consider the return type of f or other arguments as well. Even with the extension on, it would have no effect on programs which compile without it. This has nothing to do with ORF, which relies on magic type classes (although there is some overlap in what it can achieve). The primary use-case I had in mind is disambiguating name clashes between local and/or unqualified imports. Cross-posting to cafe and libraries as this doesn't seem to have attracted a lot of interest in users. Maybe it's just a boring proposal, maybe I didn't post it to the right list.

1 0

Proposal: add full complement of support for decreasing things in Data.Map
by David Feuer 20 May '16

20 May '16

Data.Map offers functions to convert from ascending lists to maps, and also offers a function to map an increasing function over the keys of a map. Equivalents for descending lists and decreasing functions are missing. I think we should add them. Any objections?

3 4

Argument order for Data.Map.adjustF
by David Feuer 20 May '16

20 May '16

I managed to find an implementation of Control.Lens.At.at for Data.Map that's fast enough to be useful. The function will be named alterF to match the name of Data.Map.alter. The remaining question is what order the arguments should go in. I had thought to follow those of alter for consistency, giving alterF :: (Functor f, Ord k) => (Maybe a -> f (Maybe a)) -> k -> Map k a -> f (Map k a) Edward Kmett thinks the ergonomics of that order are terrible, and prefers to follow lens at, giving alterF :: (Functor f, Ord k) => k -> (Maybe a -> f (Maybe a)) -> Map k a -> f (Map k a) How do other people feel about this? David Feuer

5 6

Proposal: Add a catamorphism on Trees
by David Feuer 18 May '16

18 May '16

Daniel Wagner would like to add the following straightforward function to Data.Tree. I think this is a grand idea. foldTree :: (a -> [b] -> b) -> Tree a -> b foldTree f = go where go (Node x ts) = f x (map go ts)

9 9

Re: deepseq: instance NFData (a -> b)
by Ryan Scott 08 May '16

08 May '16

I'm tentatively +1 on the idea of removing the NFData (a -> b) instance. Henning raises a good point that there are probably folks who rely on that instance to make automatic deriving of NFData. (Disclaimer: the phrase "folks" includes myself.) A similar scenario arises when deriving Show instances, for which a compromise was made by putting the Text.Show.Functions module in base, which does nothing but export an orphan Show (a -> b) instance. Perhaps, if we wanted to retain the ability to use the NFData (a -> b) instance in limited scenarios (e.g., when you're writing an application and there's no risk of leaking orphan instances to other users), then we could also introduce a Control.DeepSeq.Functions module that exports an orphan NFData (a -> b) instance, and put a giant warning at the top stating that such an instance should be used responsibly. What say ye? Ryan S.

4 6

Proposal: add chunksOf to Data.Sequence
by David Feuer 06 May '16

06 May '16

Data.List.Split.chunksOf n xs breaks up a list xs into chunks of n elements each. The internal "splitMap" function Data.Sequence uses to implement zipWith supports a simple and efficient implementation of chunksOf. All in favor, say "aye". Also, I'm still waiting for a response (any response) to my "cycleN" proposal. David

5 6

deepseq: instance NFData (a -> b)
by Henning Thielemann 01 May '16

01 May '16

According to Haddock comments, between deepseq-1.2 and deepseq-1.3 an instance for NFData on functions was introduced without previous discussion. I find this instance pretty problematic since it has no superclasses. The correct instance would be certainly something like instance (Enumerate a, NFData b) => NFData (a -> b) where Enumerate would be a new class that allows to enumerate all values of a type. This would be hardly useful because it is pretty inefficient. I'd prefer that the instance is removed, again, or even better, be replaced by a non-implementable instance. Alternatively we should replace it by a correct implementation with corresponding superclasses. If we do the second, then we could still omit the Enumerate instance for types where enumeration of all values of the type is too expensive. I assume that the instance was added to simplify automatic derivation of NFData instances. However, I think it would be better if people insert custom deepseq implementation for the expected functions then.

7 7