March 2014 - Glasgow-haskell-users

PROPOSAL: Literate haskell and module file names
by Merijn Verstraaten 23 Aug '14

23 Aug '14

Ola! I didn't know what the most appropriate venue for this proposal was so I crossposted to haskell-prime and glasgow-haskell-users, if this isn't the right venue I welcome advice where to take this proposal. Currently the report does not specify the mapping between filenames and module names (this is an issue in itself, it essentially makes writing haskell code that's interoperable between compilers impossible, as you can't know what directory layout each compiler expects). I believe that a minimal specification *should* go into the report (hence, haskell-prime). However, this is a separate issue from this proposal, so please start a new thread rather than sidetracking this one :) The report only mentions that "by convention" .hs extensions imply normal haskell and .lhs literate haskell (Section 10.4). In the absence of guidance from the report GHC's convention of mapping module Foo.Bar.Baz to Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that exists. In general this standard is nice enough, but the mapping of literate haskell is a bit inconvenient, it leaves it completelyl ambiguous what the non-haskell content of said file is, which is annoying for tool authors. Pandoc has adopted the policy of checking for further file extensions for literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs gets interpreted as being reStructured Text with literate haskell and .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps filenames like this to the module names Foo.rst and Foo.md, breaking anything that wants to import the module Foo. I would like to propose allowing an optional extra extension in the pandoc style for literate haskell files, mapping Foo.rst.lhs to module name Foo. This is a backwards compatible change as there is no way for Foo.rst.lhs to be a valid module in the current GHC convention. Foo.rst.lhs would map to module name "Foo.rst" but module name "Foo.rst" maps to filename "Foo/rst.hs" which is not a valid haskell module anyway as the rst is lowercase and module names have to start with an uppercase letter. Pros: - Tool authors can more easily determine non-haskell content of literate haskell files - Currently valid module names will not break - Report doesn't specify behaviour, so GHC can do whatever it likes Cons: - Someone has to implement it - ?? Discussion: 4 weeks Cheers, Merijn

10 17

RFC: include a cabal-install executable in future GHC releases
by Carter Schonwald 04 May '14

04 May '14

Hey everyone, I'd like to propose that GHC releases 7.8.1 onwards include a cabal-install (aka cabal) executable, but not include the library deps of cabal-install that aren't already distributed with ghc.(unless ghc should have those deps baked in, which theres very very good reasons not to do.). currently if someone wants just a basic haskell install of the freshest ghc they have to install a ghc bindist, then do a boostrap build of cabal-install by hand (if they want to actually get anything done :) ). This is not a human friendly situation for folks who are new to haskell tooling, but want to try out haskell dev on a server style vm or the like! point being: It'd be great for haskell usability (and egads amounts of config time, even by seasoned users) the ghc bindists / installers included a cabal-install binary thoughts? -Carter

15 32

can't load .so/.DLL - undefined symbol
by Henning Thielemann 11 Apr '14

11 Apr '14

I am trying to understand the following linker message. I have started GHCi, loaded a program and try to run it: Main> main ... Loading package poll-0.0 ... linking ... done. Loading package alsa-seq-0.6.0.3 ... can't load .so/.DLL for: /var/cabal/lib/x86_64-linux-ghc-7.8.0.20140228/alsa-seq-0.6.0.3/libHSalsa-seq-0.6.0.3-ghc7.8.0.20140228.so (/var/cabal/lib/x86_64-linux-ghc-7.8.0.20140228/alsa-seq-0.6.0.3/libHSalsa-seq-0.6.0.3-ghc7.8.0.20140228.so: undefined symbol: alsazmseqzm0zi6zi0zi3_SystemziPosixziPoll_zdfStorableFd_closure) I assume that GHCi wants to say the following: The instance Storable Fd defined in module System.Posix.Poll cannot be found in the shared object file of the alsa-seq package. That's certainly true because that module is in the package 'poll' and not in 'alsa-seq'. But 'alsa-seq' imports 'poll'. What might be the problem? It's a rather big example that fails here, whereas the small examples in alsa-seq package work. Thus I first like to know what the message really means, before investigating further. I installed many packages at once with cabal-install using a single build directory, like: $ cabal install --builddir=/tmp/dist --with-ghc=ghc7.8.0.20140228 poll alsa-seq pkg1 pkg2 pkg3 ... ? Can this cause problems?

2 3

GHC API: getting the unfolding of a "strange" Id
by Christiaan Baaij 04 Apr '14

04 Apr '14

Dear list, I'm using the GHC API to get Core Expressions from haskell interface (.hi) files, and have encountered a strange kind of 'Id' for which I can't seem to get the unfolding: The properties of this 'Id' are the following: - varName: $fNumFixed2 - IdDetails: VannillaId - Pretty print of IdInfo.inlinePragInfo: [Always] - IdInfo.unfoldingInfo: NoUnfolding The source file which gives rise to this 'Id' is: https://github.com/christiaanb/clash-prelude/blob/master/src/CLaSH/Sized/Fi… As you can see, the file is compiled with: -fexpose-all-unfoldings The '$f' prefix seems to indicate that the 'Id' is a Dictionary Function, so I was expecting its 'IdInfo.unfoldingInfo' to be a 'DFunUnfolding'. Given that pretty printing 'inlinePragInfo' gives me '[Always]', I would expect to have a usable 'Unfolding' in general. How can GHC inline the body of this 'Id' if it has no unfolding? Also, if I compile the file with "-O0 -fno-omit-interface-pragmas", the $fNumFixed2 'Id' is no longer included in the interface file. At positions where "$fNumFixed2" was originally used, a equality constraint can eventually be found: Using -O: (CLaSH.Sized.Fixed.$fNumFixed2 @(GHC.TypeLits.+ 4 4) Using -O0 -fno-omit-interface-pragmas: (GHC.Types.Eq# @GHC.Types.Bool @(GHC.TypeLits.<=? 1 (GHC.TypeLits.+ 4 4)) @GHC.Types.True _CO_) So my question is, what kind of "strange" 'Id' is this $fNumFixed2? And how can I get the Core expression for this 'Id' from the interface file? And if I can't get it from the interface file, is there a straightforward way to generate it from the 'Id'? Cheers, Christiaan

2 6

Haskell Support on Windows
by harry 01 Apr '14

01 Apr '14

I've been getting the impression that a lot of the stickier GHC bugs are Windows specific, while very few GHC hackers actually use Windows, other than to ensure that GHC works on it. Windows is already somewhat of a second-class citizen in Hackage, where platform-sensitive packages tend to only work out-of-the box on Linux. Perhaps it should be "demoted" to second-tier GHC support as well, at least to the extent that Windows bugs won't hold up a release? (I write this as a Windows user who also manages some Linux servers. I agree that Windows support is important, but it seems to be unreasonably "taking" far more than it "gives".) -- View this message in context: http://haskell.1045720.n5.nabble.com/Haskell-Support-on-Windows-tp5746711.h… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

2 1

SV: Haskell Support on Windows
by Niklas Larsson 31 Mar '14

31 Mar '14

Seems to me that a less pessimistic solution would be to set up a windows buildbot. Niklas ----- Ursprungligt meddelande ----- Från: "harry" <voldermort(a)hotmail.com> Skickat: ‎2014-‎03-‎31 14:27 Till: "glasgow-haskell-users(a)haskell.org" <glasgow-haskell-users(a)haskell.org> Ämne: Haskell Support on Windows I've been getting the impression that a lot of the stickier GHC bugs are Windows specific, while very few GHC hackers actually use Windows, other than to ensure that GHC works on it. Windows is already somewhat of a second-class citizen in Hackage, where platform-sensitive packages tend to only work out-of-the box on Linux. Perhaps it should be "demoted" to second-tier GHC support as well, at least to the extent that Windows bugs won't hold up a release? (I write this as a Windows user who also manages some Linux servers. I agree that Windows support is important, but it seems to be unreasonably "taking" far more than it "gives".) -- View this message in context: http://haskell.1045720.n5.nabble.com/Haskell-Support-on-Windows-tp5746711.h… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 2

Haskell Weekly News
by harry 31 Mar '14

31 Mar '14

There hasn't been a HWN since mid-December. I've emailed the editor with no response, and there doesn't seem to have been any (public) online activity from him since. I hope he's OK, but either way, it seems that HWN needs a new editor. Any volunteers? -- View this message in context: http://haskell.1045720.n5.nabble.com/Haskell-Weekly-News-tp5746682.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

1 0

Module that causes GHC-7.8 to exhaust memory when -O2 is on
by David Fox 30 Mar '14

30 Mar '14

The repository at http://src.seereason.com/o2bug contains a package that causes GHC-7.8.1 (rc2?) to exhaust 16GB of RAM and die when the -O2 flag is turned on. I haven't been able to simplify it very much, almost any change to JSON.Render causes it to start working properly. I did get it to fail using only packages available in hackage. Just thought I should let folks know about this issue. Let me know if it fails to fail. Maybe someone who can log in could put this in trac.

2 2

positive type-level naturals
by Henning Thielemann 19 Mar '14

19 Mar '14

Am 16.03.2014 09:40, schrieb Christiaan Baaij: > To answer the second question (under the assumption that you want > phantom-type style Vectors and not GADT-style): Now I like to define non-empty vectors. The phantom parameter for the length shall refer to the actual vector length, not to length-1, for consistency between possibly empty and non-empty vectors. I have modified your code as follows: {-# LANGUAGE Rank2Types #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeFamilies #-} module PositiveNat where import Data.Proxy (Proxy(Proxy)) import GHC.TypeLits (Nat, SomeNat(SomeNat), KnownNat, someNatVal, natVal, type (<=), type (+)) data Vector (n :: Nat) a = Vector a [a] withVector :: forall a b. a -> [a] -> (forall n . (KnownNat n, 1<=n) => Vector n a -> b) -> b withVector x xs f = case someNatVal $ toInteger $ length xs of Nothing -> error "static/dynamic mismatch" Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m+1) a) vecLen :: forall n . KnownNat n => Vector n Integer -> Integer vecLen _ = natVal (Proxy :: Proxy n) -- > withVector vecLen [1,2,3,4] -- 4 GHC-7.8 complains with: PositiveNat.hs:23:40: Could not deduce ((1 GHC.TypeLits.<=? (n + 1)) ~ 'True) from the context (KnownNat n) bound by a pattern with constructor SomeNat :: forall (n :: Nat). KnownNat n => Proxy n -> SomeNat, in a case alternative at PositiveNat.hs:23:13-34 In the expression: f (Vector x xs :: Vector (m + 1) a) In a case alternative: Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m + 1) a) In the expression: case someNatVal $ toInteger $ length xs of { Nothing -> error "static/dynamic mismatch" Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m + 1) a) } How can I convince GHC that n+1 is always at least 1? When I remove the (1<=n) constraint, I still get: PositiveNat.hs:23:40: Could not deduce (KnownNat (n + 1)) arising from a use of ‘f’ from the context (KnownNat n) bound by a pattern with constructor SomeNat :: forall (n :: Nat). KnownNat n => Proxy n -> SomeNat, in a case alternative at PositiveNat.hs:23:13-34 In the expression: f (Vector x xs :: Vector (m + 1) a) In a case alternative: Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m + 1) a) In the expression: case someNatVal (toInteger (length xs)) of { Nothing -> error "static/dynamic mismatch" Just (SomeNat (_ :: Proxy m)) -> f (Vector x xs :: Vector (m + 1) a) } That is, I also have to convince GHC, that if (KnownNat n) then (n+1) is also KnownNat. How to do that?

6 16

Mac CPP problem with ghc-clang-wrapper
by Christian Maeder 18 Mar '14

18 Mar '14

Hi, under mavericks using the ghc-clang-wrapper (ghc-7.6) or using ghc-7.8.20140130 I can no longer install the HaXml package. The source line: putStrLn $ "part of HaXml-"++show MAJOR.MINOR seems to put spaces around the decimal point between MAJOR and MINOR and fails as shown below. Is this already a known problem? Cheers Christian [14 of 42] Compiling Text.XML.HaXml.Wrappers ( src/Text/XML/HaXml/Wrappers.hs, dist/build/Text/XML/HaXml/Wrappers.o ) src/Text/XML/HaXml/Wrappers.hs:34:36: Couldn't match type ‛[Char]’ with ‛b0 -> c0’ Expected type: b0 -> c0 Actual type: String Possible cause: ‛show’ is applied to too many arguments In the first argument of ‛(.)’, namely ‛show 1’ In the second argument of ‛(++)’, namely ‛show 1 . 24’ src/Text/XML/HaXml/Wrappers.hs:34:36: Couldn't match expected type ‛[Char]’ with actual type ‛a0 -> c0’ In the second argument of ‛(++)’, namely ‛show 1 . 24’ In the second argument of ‛($)’, namely ‛"part of HaXml-" ++ show 1 . 24’ In a stmt of a 'do' block: putStrLn $ "part of HaXml-" ++ show 1 . 24 Failed to install HaXml-1.24

2 1