December 2017 - Libraries

Deprecating fromIntegral
by Niklas Hambüchen 12 Aug '20

12 Aug '20

This is not a joke. I just found a bug in base (https://ghc.haskell.org/trac/ghc/ticket/14262) import System.IO hWaitForInput stdin 4294968296 This code should wait for 49.something days, but it waits for 1 second. It is caused by a quick use of `fromIntegral` to "convert" `Int -> CInt` (where CInt = Int32), causing an overflow. I argue that `fromIntegral` causes unnoticed data corruption without any warning, and thus are worse than partial functions. In this case, this data corruption occurs in the most fundamental code that we all use and have to rely upon (`base`). So I propose that we add a deprecation pragma to `fromIntegral` (however, keeping it forever, like Java does, as there's no benefit to removing it, we just want that people use safer functions over time), and instead provide a `safeFromIntegral` that can only widen ranges, and one or more `unsafeFromIntegral` or appropriately named functions that can error, wrap, return Maybe, or have whatever desired behaviour when the input value doesn't fit into the output type. For some inspiration, `foundation` provides ideas in that direction: http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-From.html http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-IntegralCon… It is a bit funny how we argue that Haskell is good for high assurance programming, and we build all sorts of fancy constructs to eliminate more run-time errors, when in fact we do worse than C in detecting errors in the most basic types a computer can use, such as converting between 64-bit and 32-bit integers. Let's fix that. It avoids real problems in real production systems that are difficult to debug when they happen (who writes a unit test checking that a timeout of 50 days still works? This is the kind of stuff where you have to rely on -- very basic -- types). I'd like to probe support for such a change before doing any work on it. Niklas

18 58

Re: Storable laws
by Henning Thielemann 07 Mar '18

07 Mar '18

On Sun, 17 Dec 2017, Merijn Verstraaten wrote: > Tools like hsc2hs already pad the result of sizeOf to the appropriately > aligned size (at least the ones I've used), so this is a non-issue for > that scenario. But that's tailored to C. If I understand Sven correctly, then this is not valid for Storable.

5 7

Removing bitSize
by David Feuer 04 Feb '18

04 Feb '18

The long-deprecated bitSize method of the Bits class is slated to be removed in base-4.11 (GHC 8.4). There is one remaining question: should we replace it with a *function* by that name with a FiniteBits constraint? I don't feel very strongly either way, but Ryan Scott seems in favor and Edward Kmett seems opposed. So it seems best to bring it to the libraries list and let the CLC make the call. If the function is added, it would look like this: bitSize :: FiniteBits a => a -> Int bitSize = finiteBitSize The biggest downside I see is that we might one day want to reuse the name for something with a better type, such as bitSize :: forall proxy a. FiniteBits a => proxy a -> Int bitSize _ = finiteBitSize (undefined :: a) or bitSize :: forall a. FiniteBits a => Tagged a Int bitSize = Tagged (finiteBitSize (undefined :: a)) or (with type applications) bitSize :: forall a. FiniteBits a => Int bitSize = finiteBitSize (undefined :: a) Thanks, David Feuer

5 5

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