- Libraries - Haskell.org

Proposal: plug the space leak in transpose
by David Feuer 24 Aug '20

24 Aug '20

Data.List.transpose, unfortunately, can potentially leak space. The problem is that it walks a list of lists twice: once to get the heads and once to get the tails. Depending on the way the result is consumed, it's possible that heads or tails that are never used will be retained by the garbage collector. I have a fix[*] that probably makes the function slower in typical cases, but that plugs the leak. What do y'all say? * https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3882

2 2

exception for invalid byte sequences
by Henning Thielemann 20 Aug '20

20 Aug '20

Documentation for hGetChar et.al. [1] does not mention the exception for invalid byte sequences in the current encoding. It seems it throws an exception called "invalid argument": IO> h <- IO.openFile "/tmp/invalid" IO.ReadMode IO> IO.hGetChar h *** Exception: /tmp/invalid: hGetChar: invalid argument (invalid byte sequence) https://hackage.haskell.org/package/base-4.14.0.0/docs/System-IO.html#v:hGe…

1 0

Module naming help
by David Feuer 20 Aug '20

20 Aug '20

I'm really close to making a second release of the compact-sequences package (now with deques!), but I'd like to get a bit of help with module naming/renaming now to try to avoid more painful name changes later, when my package will hopefully have actual users. Currently, I have three "base" implementations, Data.CompactSequence.Stack.Internal Data.CompactSequence.Queue.Internal Data.CompactSequence.Deque.Internal Each of these implements an abstract datatype representing a stack/queue/deque of fixed-size arrays. Additionally, I have "simple" implementations Data.CompactSequence.Stack.Simple Data.CompactSequence.Queue.Simple Data.CompactSequence.Deque.Simple that just use the base implementations with arrays of size 1. These are great as a proof of concept and for testing, but I expect their performance to be quite bad [1]. To solve the problem, I need to write separate datatypes to handle the top of the structure (the first k elements of a stack, or a prefix and suffix of a queue or deque). There are various different approaches to this, with various trade-offs and tuning factors. The first I'd like to implement, for stacks and queues, would look exactly like the base implementations but with elements instead of arrays in the first node. What might I call these? Another option would be to just use linked lists with various length bounds. Yet another would use stacks that look like data Stack6 a = One a | Two a a | ... | Six a a a a a a for various size bounds. But I have no idea how to name any of these things. A second issue: I may eventually want to add alternative base implementations to support O(log n) `length` and significantly more efficient (but still O(n)) splitting, appending, and indexing operations. How might *those* work into the name situation? Finally, I'll eventually want to offer support for unpacked data, probably via backpack. That will involve base implementations that work with ByteArray rather than SmallArray. Names, names, I hate names! 1. In the first node of the data structure, each sequence element is represented as a pointer to a SmallArray of one element. Yuck. The situation improves considerably further in, with the array size doubling in successive nodes. 2. For deques, where code size is already a matter of some concern, this approach seems likely to exacerbate the issue, but a simpler variant should work well enough.

1 0

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