- Libraries - Haskell.org

Null Pointer Pattern
by Andrew Martin 18 Aug '20

18 Aug '20

Foreign.Ptr provides nullPtr. It would make some of my code more terse if this was additionally provided as a pattern synonym. The pattern synonym can be defined as: {-# language ViewPatterns #-} {-# language PatternSynonyms #-} module NullPointerPattern ( pattern Null ) where import Foreign.Ptr (Ptr,nullPtr) pattern Null :: Ptr a pattern Null <- ((\x -> x == nullPtr) -> True) where Null = nullPtr Any here is example of code that becomes more terse once this is available: foo :: IO (Either Error (Ptr Foo)) foo = do p <- initialize mySettings if p == nullPtr then pure (Left InitializeFailure) else pure (Right p) With the pattern synonym, we are able to take advantage of LambdaCase: foo :: IO (Either Error (Ptr Foo)) foo = initialize mySettings >>= \case Null -> pure (Left InitializeFailure) p -> pure (Right p) I'm curious what others think. -- -Andrew Thaddeus Martin

4 7

Cabal: N executables without building all the modules N times?
by James Cook 16 Aug '20

16 Aug '20

Hi libraries@, (Let me know if there's a better place for Cabal questions. This list is linked from https://www.haskell.org/cabal/ as a place to ask questions.) I have a project with lots of modules, and lots of executables that use those modules. How should I structure my .cabal file if I want cabal to only build the common modules once? I have found I can do it as follows, but I am wondering if there's a way to do it without step 1: 1. Create a "library_src" directory with the source for all the shared modules. Put the source files for the executables somewhere else. 2. Create a .cabal file with one "library" stanza with "hs-source-dirs: library_source", and several executable stanzas. If I leave out step 1 and put all the source files in the same place, then the compiler builds them separately for each executable, and I get a "missing-home-modules" warning. Is it just a fact of life that I need to separate my source into separate directories if I want this to work properly? Here's a small example, with four files, where I left out step 1 (i.e. put everything in the same directory). It does not behave the way I want it to: it builds the Library module three times if I run "cabal v2-build" and "cabal v2-test", and it shows the "missing-home-modules" warning. It also still builds if I remove "mhm" from build-depends of the executable and test-suite; I'd rather it failed to build if I did that. mhm.cabal: cabal-version: 2.2 name: mhm version: 0 library exposed-modules: Library default-language: Haskell2010 build-depends: base >=4.12 && <4.13 executable e main-is: e.hs build-depends: mhm, base >=4.12 && <4.13 default-language: Haskell2010 test-suite t type: exitcode-stdio-1.0 main-is: t.hs build-depends: mhm, base >=4.12 && <4.13 default-language: Haskell2010 Library.hs: module Library where n :: Int n = 5 e.hs: module Main where import Library main = print n t.hs: module Main where import Library main = print n

3 3

"Core Libraries Committee" vs. "Library_submissions" page
by Howard B. Golden 13 Aug '20

13 Aug '20

It appears that the Haskell Wiki's "Core Libraries Committee <https://wiki.haskell.org/Core_Libraries_Committee>" page is up-to-date. There is a lot of (out-of-date) redundancy on the "Library_submissions <https://wiki.haskell.org/Library_submissions>" page. Perhaps these pages can be rearranged. I suggest that the "Core Libraries Committee" page identify the administration performed by the committee. The specific links to Libraries might be better in the "Library_submissions" (perhaps just renamed "Libraries") with a link from the CLC page. (Or maybe transcluded?) Howard

2 1

Please update the Library_submissions page on the Haskell Wiki
by Howard B. Golden 13 Aug '20

13 Aug '20

Hi, The Library_submissions page <https://wiki.haskell.org/Library_submissions> is out-of-date due to dead links to old servers (e.g. GHC Trac). Please update the links to help users contact the right maintainer or issue tracker. Thanks. Howard

1 0

Re: Deprecating fromIntegral
by Andrew Lelechenko 13 Aug '20

13 Aug '20

> From: Edward Kmett <ekmett(a)gmail.com> > > fromIntegralMaybe :: (Integral a, Num b) => a -> Maybe b > fromIntegralMaybe = fromIntegerMaybe . toInteger I’m late to the party, so might be missing something. Did someone already proposed using http://hackage.haskell.org/package/base-4.14.0.0/docs/Data-Bits.html#v:toIn…, which has a very similar signature? toIntegralSized :: (Integral a, Integral b, Bits a, Bits b) => a -> Maybe b No need for O(n^2) instances and it is already in `base`. Best regards, Andrew

4 4

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

Proposal: export more from Data.Kind
by Krzysztof Gogolewski 03 Aug '20

03 Aug '20

Hello, I'd like to export TYPE, RuntimeRep(..), Multiplicity(..) from Data.Kind. (Multiplicity is the Linear Haskell type - One and Many.) Currently you have to import GHC.Exts / GHC.Types which conflicts with Safe Haskell. I think both levity and linearity polymorphism should be available under Safe Haskell. Data.Kind already contains Constraint and Type. -Krzysztof

5 6

Alternative instance for Compose
by Asad Saeeduddin 20 Jul '20

20 Jul '20

Hello folks, base 4.14 has the following instance for `Compose f g`: instance (Alternative f, Applicative g) => Alternative (Compose f g) where empty = Compose empty (<|>) = coerce ((<|>) :: f (g a) -> f (g a) -> f (g a)) :: forall a . Compose f g a -> Compose f g a -> Compose f g a This instance doesn't really do anything with the `Applicative g` constraint it is demanding. It's also kind of unclear what utility it delivers, given that the resulting Alternative instance is indistinguishable from the outer functor's Alternative instance. In other words: `getCompose $ Compose x <|> Compose y == x <|> y`. It seems to me a more useful instance would be: instance (Applicative f, Alternative g) => Alternative (Compose f g) where empty = Compose $ pure empty (<|>) = _ $ liftA2 (<|>) This is also nicer in a mathematical sense: `Applicative` functors correspond to lax monoidal functors from `Hask, (- , -), ()` to `Hask, (-, -), ()`. We can interpret `Alternative`s as lax monoidal functors from `Hask, Either - -, Void` to `Hask, (-, -), ()`. Compatible lax monoidal functors compose, but if you think about the relevant "types" of the functors a bit, you'll realize that while we can compose an `Applicative` after an `Alternative` to get another `Alternative`, the reverse does not work. Hence the instance we have today, which has no choice but to just ignore the `Applicative` constraint it is demanding. Does it make sense to replace the instance we have today with the `pure empty`, `liftA2 (<|>)` one? Thanks, Asad

2 1

Laziness on new "random" package
by Dannyu NDos 17 Jul '20

17 Jul '20

Though it is reasonable to make utilities monadic, they lack a crucial property: *laziness*. I have the following datatype: newtype ArbReal = ArbReal (Word -> Integer) This represents arbitrary real numbers by being able to compute arbitrary decimal places after the decimal point. For example, to compute pi, let f be the function passed to constructor ArbReal. Then f 0 = 3, f 1 = 31, f 2 = 314, and so on. I can implement instance Random ArbReal: instance Random ArbReal where random g = let (h, i) = split g d:digits = randomRs (0 :: Word, 9) h getNum [] = 0 getNum (d:ds) = toInteger d + 10 * getNum ds takeDigits n = getNum (reverse (take n digits)) + toInteger (fromEnum (d >= 5)) in (ArbReal (takeDigits . fromIntegral), i) randomR (lo, hi) g = let (x, h) = random g in (lo + x * (hi - lo), h) But I see no way to implement an instance of UniformRange ArbReal, for it relies on randomRs, which is lazy. Neither ST nor IO is able to contain such laziness.

2 1

Looking for co-maintainers(s) for github package.
by Oleg Grenrus 16 Jul '20

16 Jul '20

Hi list, I have now been a maintainer of `github` [1] package for about four years. GitHub still develops and changes their API (good) and still doesn't provide machine readable specification (bad), thus the package needs some active maintenance. As I'm not using the package anymore myself, I often forget about its existence. Therefore I'm looking for a (co-)maintainers which use `github` package themselves, and could eventually take over the maintenance. In the past year I haven't written any code for the package myself, only reviewing and merging other people contributions, and preparing releases when there are enough changes. I don't ask you to do anything else either. - Oleg "phadej" Grenrus [1]: https://hackage.haskell.org/package/github

1 0