- Libraries - Haskell.org

Re: Proposal: Lifting to TExpQ
by Dan Burton 15 Jan '18

15 Jan '18

+1 to Michael's suggestion; that's basically the same thing I would have suggested, modulo bikeshedding. On Jan 13, 2018 15:03, "Michael Sloan" <mgsloan(a)gmail.com> wrote: Hmm, I'm not sure about changing the Lift class, there are good reasons to leave it the same and good reasons to change as well. There is a lot of precedent for providing safe functions which use unsafe functions (e.g. unsafeDupablePerformIO in bytestring / text). Also, not much of the TH API uses TExp, just typed splices. On the other hand, it does make the method's type stronger and directly suggest more properties. It may encourage people to use typed splices to define manual instances, which I think is good. I propose a somewhat less breaking change, defining the following: class Lift t where typedLift :: t -> Q (TExp t) lift :: Lift t => t -> Q t lift = fmap unType . typedLift The advantage of this is that a lot more code depends on usage of 'lift' than defining instances of 'Lift'. A lot of the code that defines instances of 'Lift' does it via the 'th-lift' package. I believe that only a handful of packages would need to be updated as a result of this change, vs the dozens that would need to be updated by changing the type of 'lift'. Even after this change, I think that since 'TExp' is only useful with typed splices, the 'lift' form would still find much more usage as the more convenient function. -Michael _______________________________________________ Libraries mailing list Libraries(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

3 2

Proposal: Lifting to TExpQ
by Emil Axelsson 13 Jan '18

13 Jan '18

Hi! I wasn't able to find a function like this anywhere: liftT :: Lift a => a -> TExpQ a liftT = unsafeTExpCoerce . lift It seems like a nice addition that would reduce the need for `unsafeTExpCoerce` in user code. Should it be added? / Emil

3 3

Proposal: add unzips for Data.Sequence
by David Feuer 12 Jan '18

12 Jan '18

Paolo G. Giarrusso (Blaisorblade) would like to add an unzip function to Data.Sequence. I agree. I propose adding unzip :: Seq (a,b) -> (Seq a, Seq b) unzipWith :: (x -> (a, b)) -> Seq x -> (Seq a, Seq b) Does anyone object?

5 6

Constraint implication
by Ryan Reich 02 Jan '18

02 Jan '18

The Constraint kind appears to lack an interface to an important capability that is already part of the type checker: constraint implication. Namely, the ability to provide a witness for the statement "constraint c1 implies constraint c2" or, more importantly, "for all a, constraint (c1 a) implies constraint (c2 a)", where c1 and c2 are now constraint-valued type functions (and possibly even for constraint functions with multiple parameters). It seems to me that this can follow the pattern of the "magic" Coercible type class and the (non-magic) Coercion data type; it provides the programmer with an analogous value to this example that can be obtained in apparently no other way.

5 6

add a new equation to Data.Type.Bool.If
by Richard Eisenberg 29 Dec '17

29 Dec '17

Currently, we have (in Data.Type.Bool): > -- | Type-level "If". @If True a b@ ==> @a@; @If False a b@ ==> @b@ > type family If cond tru fls where > If 'True tru fls = tru > If 'False tru fls = fls I propose adding a new equation, thus: > -- | Type-level "If". @If True a b@ ==> @a@; @If False a b@ ==> @b@ > type family If cond tru fls where > If b same same = same > If 'True tru fls = tru > If 'False tru fls = fls This new equation would allow If to reduce when we don't know the condition but we do know that both branches are the same. All three equations are *compatible* (a technical term defined in the closed type families paper), meaning that GHC ignores the ordering between them and will just choose whichever equation matches. Any objections? Thanks, Richard

3 5

Proposal: simplify type of ($)
by David Feuer 28 Dec '17

28 Dec '17

Currently, we have something like ($) :: forall r1 r2 (a :: TYPE r1) (b :: TYPE r2). (a -> b) -> a -> b f $ x = f x And that's only part of the story: GHC has a hack in the type checker to give ($) an impredicative type when fully applied. This allows it to be used when its function argument requires a polymorphic argument. This whole complicated situation could be resolved in a very simple manner: change the type and definition thus. ($) :: a -> a ($) f = f All the type complications go away altogether, and ($) becomes plain Haskell 98. There are only three potential downsides I can think of: 1. The optimizer will see `($) x` as fully applied, which could change its behavior in some cases. There might be circumstances where that is bad. I doubt there will be many. 2. The new type signature may obscure the purpose of the operator to beginners. But based on my experience on StackOverflow, it seems beginners tend to struggle with the idea of ($) anyway; this may not make it much worse. I suspect good Haddocks will help alleviate this concern. 3. Some type family and class instances may not be resolved under certain circumstances which I suspect occur very rarely in practice. class C a where m :: (a -> a) -> () instance C (a -> b) where m _ = () test :: () test = m ($) Today, this compiles with no difficulties; with the proposed change, the user would have to supply a type signature to make it work: test = m (($) :: (a -> b) -> (a -> b)) This can also change when an INCOHERENT instance is selected under similarly contrived circumstances, but those who use such generally deserve what they get. David

5 7

PROPOSAL: Add `disjoint` method to `Data.IntSet`
by Víctor López Juan 27 Dec '17

27 Dec '17

Proposal: Add a method disjoint :: IntSet → IntSet → Bool, to Data.IntSet, such that prop> disjoint a b ≡ null (intersection a b) Alternatively or additionally, add a method overlaps :: IntSet -> IntSet -> Bool such that prop> a `overlaps` b ≡ not.null$ intersection a b Rationale: - I have found it useful to have such a method when keeping track of the set of free-variables in a term. I believe that there can be more use cases. - There are already similar specialized implementations in the library. For example, isSubsetOf :: IntSet -> IntSet -> Bool is such that prop> a `isSubsetOf` b ≡ (a == (a `intersection` b)). - Having `disjoint`, the user can also check whether two sets overlap with `(not.).disjoint`. This is shorter and more self-explaining than (not.null$ intersection). - A specialized implementation of `disjoint` (vs. (null.).intersection) can shortcircuit as soon as the sets overlap on one element. This leads to significant speed-ups; for example, 23× when checking that the sets {1,2,3…,2¹²} and {2,4,6,…,2¹²} are not disjoint [1]. Discussion: I would like to get some comments on this proposal. In particular: - Should any of these methods be added? - Should both `overlaps` and `disjoint` be added? - If only one of them is added, which one should it be? I hope a decision about the proposal can be reached before 2018-01-09. See also: - Proposed patch [2] - Previous discussion [3] [1] https://github.com/haskell/containers/pull/377#issuecomment-352585171 [2] https://github.com/haskell/containers/pull/377/files [3] https://github.com/haskell/containers/pull/377

8 8

Constrained Dynamic variant
by Ryan Reich 27 Dec '17

27 Dec '17

I have found it useful to use Dynamic-like existential types such as (fake example): > data Number = forall a. (Num a, Typeable a) => Number a which supports precisely the same API as Dynamic, but with a Num constraint on everything. However, writing that API for this particular type requires copy-pasting the definitions of fromDyn and fromDynamic as boilerplate, which is (ahem) stupid. Now that we have the Constraint kind, it is possible to generalize this in a form suitable for Data.Dynamic: > data CDynamic (c :: Type -> Constraint) = forall a. (c a) => CDynamic (TypeRep a) a > > toCDyn :: (c a, Typeable a) => a -> CDynamic c > fromCDyn :: (c a, Typeable a) => CDynamic c -> a -> a > fromCDynamic :: (c a, Typeable a) => CDynamic c -> Maybe a > relaxCDyn :: CDynamic c -> Dynamic > dynApplyC :: CDynamic c1 -> CDynamic c2 -> Maybe Dynamic > dynAppC :: CDynamic c1 -> CDynamic c2 -> Dynamic > dynTypeRepC :: CDynamic c -> SomeTypeRep > > instance Show (CDynamic c) > instance Exception (CDynamic c) > > class NoC a where -- intentionally empty, can be used unsaturated > instance NoC a where -- also empty > type Dynamic = CDynamic NoC > > -- Specializations of all the above functions I think it's clear how to fill in the definitions. I added an apparently necessary function relaxCDyn that also does the obvious thing; I'm not really happy with its type signature but offhand I can't say how to generalize it. I think this is useful, and if I'm not missing anything (obvious or subtle) about it, I want to propose that it goes into Data.Dynamic.

2 1

Adding a member to the Haskell organization
by David Feuer 24 Dec '17

24 Dec '17

Matt Renaud (GitHub user m-renaud) has agreed to join the containers maintenance team. Could someone with the power please add him to the Haskell organization on GitHub?

2 1

Proposal: add `Proxy`fied versions of `bitSizeMaybe` and `finiteBitSize`
by M Farkas-Dyck 19 Dec '17

19 Dec '17

I propose to add the following methods to `Bits` and `FiniteBits` classes: class Bits a where ... bitSizeMaybe' :: Proxy a -> Maybe Int class FiniteBits b where ... finiteBitSize' :: Proxy b -> Int Rationale: working with an arbitrary `Bits a => a`, one may not have a value of type `a` as argument to `bitSizeMaybe` or `finiteBitSize`, and writing `undefined` makes me feel dirty.

8 14