August 2020 - Libraries

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