- Libraries - Haskell.org

Re: Names for general merge tactics in Data.Map
by David Feuer 19 Aug '16

19 Aug '16

Consider them severed. I'm most interested in getting generalMerge settled. I can leave the question of what to do with mergeWithKey alone for a while. On Aug 19, 2016 12:59 AM, "Bardur Arantsson" <spam(a)scientician.net> wrote: On 2016-08-18 22:40, David Feuer wrote: > I like the idea of using separate modules. What would you like them to > be called? > > I am open to the idea of leaving mergeWithKey in, but I'm not yet > convinced. Can you give an example of a realistic application of > mergeWithKey that cannot easily be rewritten in terms of generalMerge? > I would normally agree with you that backwards compatibility should be > preserved. However, mergeWithKey has several very serious problems. > > 1. It allows the user to produce invalid maps. Unlike other functions > that do so, it's not clear that it offers any significant efficiency > benefit (once generalMerge is added). > > 2. It breaks the map abstraction. A user could invoke mergeWithKey > with arguments that cause it to produce semantically different maps > depending on the way the given map is balanced. For example, a user > could pass an only1 function that deletes the median of the tree it is > passed. I don't know how to document the appropriate restrictions > required to preserve the abstraction. > > 3. It is very hard to figure out much about what mergeWithKey does by > looking at its name and type. Indeed, I did not understand it from its > documentation either, and had to read the source code. > Maybe it would be better to de-copule this into two proposals, one for adding generalMerge (or whatever it ends up being called #bikeshed), and one for depracting/removing mergeWithKey? _______________________________________________ Libraries mailing list Libraries(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

2 1

type synonyms for dynamic imports and wrappers
by Henning Thielemann 18 Aug '16

18 Aug '16

The Haskell FFI report says that imports and exports of dynamic functions always have those types: foreign import ccall "dynamic" mkFun :: FunPtr fun -> fun foreign import ccall "wrapper" mkCallback :: fun -> IO (FunPtr fun) where 'fun' is an IO function. Since 'fn' can be a considerably large type expression I usually define type Importer fun = FunPtr fun -> fun type Exporter fun = fun -> IO (FunPtr fun) How about adding these type synonyms to Foreign?

2 1

Backwards breaking change for setEnv
by Edward Z. Yang 17 Aug '16

17 Aug '16

Hello all, I wanted to bring this bug to the attention of the CLC https://ghc.haskell.org/trac/ghc/ticket/12494#ticket I propose that we change 'setEnv k ""' to set the environment variable to an empty string, rather than delete the environment variable. The existing behavior was motivated by a Windows "quirk" that actually doesn't exist (details in ticket.) Thanks, Edward

5 5

Proposal and discussion: Add MonadFail instance to Either
by Tobias Markus 14 Aug '16

14 Aug '16

As suggested in the GHC Trac [1], it would be nice to have a MonadFail instance for Either. The original suggestion by lexi.lambda was instance MonadFail (Either String) where fail = Left However, it was rightfully pointed out that this instance is overly specific. The discussion arrived at the following alternative proposed by Iceland_jack: instance IsString str => MonadFail (Either str) where fail = Left . fromString For previous discussion on this proposal, please take a look at the Trac thread. I am looking forward to your input! Tobias [1] GHC Trac Ticket #12160, https://ghc.haskell.org/trac/ghc/ticket/12160 -- Tobias Markus "They who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790)

3 2

Data.Set optimisations [was: [Haskell-cafe] library for set of heterogeneous values?]
by Anthony Clayden 14 Aug '16

14 Aug '16

Firstly, to correct myself: > Contrast that with Data.Set [*], you could stream the contents to a list and filter. > (Which would be horribly inefficient for my purposes.) Thank you Libraries team. Data.Set seems to have been seriously revamped since I last looked, and now includes a 'proper' filter function. (It used to stream the Set to a List; filter the List; build a new Set.) > [*] Data.Set seems to have been swallowed into the new collections library, > which is not currently maintained Uhh. That was a dead link (of ~10 years ago, but Google still took me to it). Data.Set is in the **containers** library supported on hackage. But I have some q's about the optimisations: The hedge-union algorithm seems to have been taken out, as inefficient. (per treeowl on github). But the code on hackage still uses hedge?? So the docos are out of date. (And quite a bit of commentary on StackOverflow.) Was it really not more efficient? The Set data type's constructors got reordered (Bin is now first, Tip is second). On grounds it "improves the benchmark by up to 10%". Are you sure it makes that much difference? Are you sure it makes any difference at all? The culprit seems to be pattern matching. It makes me feel there's something seriously wrong with GHC's code generator. (And the semantics of ADTs is that the first constructor is ordered first if you go `deriving (Ord)`. So there's usually a design reason driving the ordering of constructors -- eg Nothing ordered before Just; [] ordered before (:), which makes String ordering do the right thing.) Set is a purely functional data structure, no in-situ updating of nodes, no pointer semantics unlike imperative/low-level implementations of balanced binary trees. That means Tips (empty end-points) genuinely get allocated/built and accessed and garbaged on insert -- or does all that strictness annotation/INLINing alter that? Contrast that in an imperative/low-level model they'd be null pointers, nothing allocated. Note the number of Tips is equal the number of values in the tree, + 1. Would it save construction/destruction/access overhead to have three extra constructors? | both sub-trees are empty | left (only) is empty | right (only) is empty If it's true per above that each constructor adds a performance penalty just doing the pattern matching, I guess the answer is 'no' :-( Thanks AntC >>

1 0

Re: Map mashing function
by David Feuer 09 Aug '16

09 Aug '16

I was wrong. It's possible to write the general safe merge function in Haskell 98, by replacing the GADT with a record of functions. Sorry for the confusion! On Aug 8, 2016 11:08 AM, "Edward Kmett" <ekmett(a)gmail.com> wrote: > You could always bury the GADT in an internal module with whatever > super-general API you expose that uses it. ;) > > Then I can have a sexy profunctor instance. > > -Edward > > On Mon, Aug 8, 2016 at 10:55 AM, Ryan Trinkle <ryan.trinkle(a)gmail.com> > wrote: > >> Ah, that sounds interesting! I'm not really sure there's much value to >> exposing the GADT, so perhaps it would be better to keep it abstract. >> Plus, you can always open it up later, but doing a deprecation cycle if you >> decide it needs to be abstract will be super painful. So i guess I'd tend >> to think that abstract is the safer option. >> >> On Mon, Aug 8, 2016 at 10:28 AM, David Feuer <david.feuer(a)gmail.com> >> wrote: >> >>> Thanks! One more question: should I export the GADT constructors, or >>> just bindings for them? The (theoretical) advantage of the latter is that I >>> can enforce equivalences >>> >>> dropC == mapFilterC (\_ _ -> Nothing) >>> >>> and >>> >>> preserveC == mapFilterC (\_ v -> Just v) >>> >>> I think this lets us write >>> >>> instance Functor f => Functor (MergeTactic f k v) where >>> fmap _ Drop = Drop >>> fmap f Preserve = MapFilter (\_ -> Just . f) >>> fmap f (MapFilter p) = MapFilter (\k x -> f <$> p k x) >>> fmap f (TraverseFilter p) = TraverseFilter (\k x -> fmap f <$> p k x) >>> >>> and I think this lets profunctors write >>> >>> >>> instance Functor f => Profunctor (MergeTactic f k) where >>> dimap _ _ Drop = Drop >>> dimap f g Preserve = MapFilter (\_ -> Just . g . f) >>> dimap f g (MapFilter p) = MapFilter (\k x -> g <$> p k (f x)) >>> dimap f g (TraverseFilter p) = TraverseFilter (\k x -> fmap g <$> p k >>> (f x)) >>> >>> >>> On Aug 8, 2016 9:59 AM, "Ryan Trinkle" <ryan.trinkle(a)gmail.com> wrote: >>> >>>> Wow, that looks great! I wasn't expecting something that clean or that >>>> general. >>>> >>>> The choice of INLINE or INLINABLE is above my pay grade, but I'm sure >>>> this will be a huge improvement either way! >>>> >>>> On Mon, Aug 8, 2016 at 9:48 AM, David Feuer <david.feuer(a)gmail.com> >>>> wrote: >>>> >>>>> Is this good? https://github.com/haskell/con >>>>> tainers/pull/317/files#diff-52bcc964836f9c44f05804a0c2267321R1904 >>>>> >>>>> Ryan: I worked out a general map combining function, with some help >>>>> from Dan Doel and Cale, that I think gets most of what you'd want from such >>>>> a thing without the horrors of mergeWithKey. >>>>> >>>>> Both of you: I changed the Applicative actions to make sure they're >>>>> entirely deterministic (going strictly in key order, interleaving actions >>>>> associated with A-B, B-A, and A /\ B) without depending on tree balance. I >>>>> decided that while it makes the most sense for the function to be in the >>>>> middle, it's most convenient for it to be after the tactics, so I did that. >>>>> If you disagree, let me know. Also, feedback on the type and constructor >>>>> names would be great. Currently, the function is marked INLINE, like >>>>> mergeWithKey. Should I mark it INLINABLE instead, and let users who want to >>>>> be sure use an explicit `inline` call? >>>>> >>>> >>>> >> >

3 3

More Data.Set and Data.Map operations
by David Feuer 09 Aug '16

09 Aug '16

Cale Gibbard and Ryan Trinkle are interested in adding some more operations they say will be useful in their work. Note that unionWithMapping is intended to enable an efficient implementation of alignWith in Data.Align in the `these` package. Set: filterIncreasing :: Ord a => (a -> Bool) -> Set a -> Set a filterDecreasing :: Ord a => (a -> Bool) -> Set a -> Set a partitionIncreasing :: Ord a => (a -> Bool) -> Set a -> (Set a, Set a) Map: filterKeysIncreasing :: Ord k => (k -> Bool) -> Map k a -> Map k a filterKeysDecreasing :: Ord k => (k -> Bool) -> Map k a -> Map k a partitionKeysIncreasing :: Ord k => (k -> Bool) -> Map k a -> (Map k a, Map k a) traverseMaybe :: Applicative f => (a -> f (Maybe b)) -> Map k a -> f (Map k b) alterMany :: Ord k => (a -> Maybe b -> Maybe b) -> Map k a -> Map k b -> Map k b alterManyA :: (Applicative f, Ord k) => (a -> Maybe b -> f (Maybe b)) -> Map k a -> Map k b -> f (Map k b) unionWithMapping :: Ord k => (a -> c) -> (b -> c) -> (a -> b -> c) -> Map k a -> Map k b -> Map k c unionWithKeyMapping :: Ord k => (k -> a -> c) -> (k -> b -> c) -> (k -> a -> b -> c) -> Map k a -> Map k b -> Map k c

7 17

Data.Fixed Missing E4, E5, etc
by Andrew Martin 04 Aug '16

04 Aug '16

I've been working on a library for parsing geolite's GeoIP csv file (http://hackage.haskell.org/package/geolite-csv-0.2/docs/Geolite-Types.html) In this file, the latitude and longitude are always given to four decimal points of precision. It seems like the Fixed data type (from Data.Fixed in base) is the best choice for representing this. However, the precision levels provided are: - E0 - E1 - E2 - E3 - E6 - E9 - E12 I would like to propose adding all of the missing ones into Data.Fixed as well. Even though needed a four-decimal-point-precision number is uncommon, it's not unheard of. Admittedly, the precision offered by E11 seems unlikely to ever be needed, but I think it would be nice for completeness. I would be happy to PR this if others agree that it's a good idea. -Andrew Martin

4 6

MonadFix instance for Q
by Joe Hermaszewski 03 Aug '16

03 Aug '16

Q is capable of being an instance of MonadFix, I've opened a ticket here, I'd appreciate it if someone could take a look: https://ghc.haskell.org/trac/ghc/ticket/12073 ``` instance MonadFix Q where mfix k = do m <- runIO newEmptyMVar ans <- runIO (unsafeInterleaveIO (takeMVar m)) result <- k ans runIO (putMVar m result) pure result ```

1 0

Proposal: Add gcoerceWith to Data.Type.Coercion
by David Feuer 22 Jul '16

22 Jul '16

In Data.Type.Equality, we have both castWith :: (a :~: b) -> a -> b and gcastWith :: (a :~: b) -> (a ~ b => r) -> r But in Data.Type.Coercion we only have coerceWith :: Coercion a b -> a -> b It seems to me that for the sake of consistency, we should add gcoerceWith :: Coercion a b -> (Coercible a b => r) -> r gcoerceWith Coercion a = a David Feuer

4 3