- Glasgow-haskell-users

type checker plugin does not affect inferred type signatures
by adam vogt 16 Feb '15

16 Feb '15

Hello, Using ghc-7.10 rc1, I am trying to write a type checker plugin that adds wanted constraint which helps ghc to infer more types. However, it seems that the wanted constraints I add don't get added to the inferred type of the declaration, so that I get a type error like: a.hs:1:1: Warning: Could not deduce (SameLength y x) arising from an application from the context (HLength x ~ HLength y) bound by the inferred type of p :: (HLength x ~ HLength y) => Proxy '(y, x) at a.hs:11:1-69 I think ghc should be able to figure out p :: (SameLength x y, HLength x ~ HLength y) => Proxy '(x,y). The code is self-contained: git clone https://github.com/aavogt/HListPlugin cd HListPlugin/ex make Is this approach supposed to be possible, or am I supposed to rewrite things such that I only produce CtGivenS from the plugin? Regards, Adam

2 2

Injective type families for GHC
by Jan Stolarek 10 Feb '15

10 Feb '15

Haskellers, I am finishing work on adding injective type families to GHC. I know that in the past many people have asked for this feature. If you have use cases for injective type families I would appreciate if you could show them to me. My implementation has some restrictions and I want to see how severe these restrictions are from a practical point of view. Janek --- Politechnika Łódzka Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

2 3

GHC 7.10 Prelude: we need your opinion
by Simon Peyton Jones 10 Feb '15

10 Feb '15

Haskell Friends This email asks for your help in deciding how to proceed with some Prelude changes in GHC 7.10. Please read on, but all the info is also at the survey link, here: http://goo.gl/forms/XP1W2JdfpX. Deadline is 21 Feb. The Core Libraries Committee (CLC) is responsible for developing the core libraries that ship with GHC. This is an important but painstaking task, and we owe the CLC a big vote of thanks for taking it on. For over a year the CLC has been working on integrating the Foldable and Traversable classes (shipped in base in GHC 7.8) into the core libraries, and into the Prelude in particular. Detailed planning for GHC 7.10 started in the autumn of 2014, and the CLC went ahead with this integration. Then we had a failure of communication. As these changes affect the Prelude, which is in scope for all users of Haskell, these changes should be held to a higher bar than the regular libraries@ review process. However, the Foldable/Traversable changes were not particularly well signposted. Many people have only recently woken up to them, and some have objected (both in principle and detail). This is an extremely unfortunate situation. On the one hand we are at RC2 for GHC 7.10, so library authors have invested effort in updating their libraries to the new Prelude. On the other, altering the Prelude is in effect altering the language, something we take pretty seriously. We should have had this debate back in 2014, but here we are, and it is unproductive to argue about whose fault it is. We all share responsibility. We need to decide what to do now. A small group of us met by Skype and we've decided to do this: · Push back GHC 7.10's release by at least a month, to late March. This delay also gives us breathing space to address an unrelated show-stopping bug, Trac #9858. · Invite input from the Haskell community on which of two approaches to adopt (this survey<http://goo.gl/forms/XP1W2JdfpX>). The main questions revolve around impact on the Haskell ecosystem (commercial applications, teaching, libraries, etc etc), so we want to ask your opinion rather than guess it. · Ask Simon Marlow and Simon Peyton Jones to decide which approach to follow for GHC 7.10. Wiki pages have been created summarizing these two primary alternatives, including many more points and counter-points and technical details: · Overall summary: https://ghc.haskell.org/trac/ghc/wiki/Prelude710<https://www.google.com/url?q=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fw…> · Details of Plan List: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List<https://www.google.com/url?q=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fw…> · Details of Plan FTP: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP<https://www.google.com/url?q=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fw…> This survey invites your input on which plan we should follow. Would you please · Read the details of the alternative plans on the three wiki pages above · Add your response to the survey<http://goo.gl/forms/XP1W2JdfpX> Please do read the background. Well-informed responses will help. Thank you! DEADLINE: 21 February 2015 Simon PJ

3 3

Proposal: ValidateMonoLiterals - Initial bikeshed discussion
by Merijn Verstraaten 10 Feb '15

10 Feb '15

I've been repeatedly running into problems with overloaded literals and partial conversion functions, so I wrote up an initial proposal (https://ghc.haskell.org/trac/ghc/wiki/ValidateMonoLiterals) and I'd like to commence with the bikeshedding and hearing other opinions :) Cheers, Merijn

9 19

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 2
by Herbert Valerio Riedel 07 Feb '15

07 Feb '15

Hi Mark, On 2015-01-28 at 04:31:29 +0100, Mark Lentczner wrote: > I've just built a bindist under 10.10, but just normal not expressly llvm. > I'll test this in a bit then post it -- but might be sometime tomorrow > before it is up. How's progress on this btw? Are you also working on a GHC 7.8.4 OSX bindist by any chance? Cheers, hvr

3 2

Restricted Template Haskell
by Greg Weber 03 Feb '15

03 Feb '15

Hello GHC friends! I am starting up a proposal for variants of Template Haskell that restrict what operations are available. The goal is to make TH easier for users to reason about and to allow for an easier compilation story. Here is the proposal page: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted Right now the proposal does not have any details and the goal is to write out a clear specification. If this sounds interesting to you, let me know or leave some feedback on the wiki. Thanks, Greg Weber

3 6

stream fusion, concatMap, exisential seed unboxing
by Christian Höner zu Siederdissen 02 Feb '15

02 Feb '15

Hi everybody, I'm playing around with concatMap in stream fusion (the vector package to be exact). concatMapM :: Monad m => (a->m (Stream m b)) -> Stream m a -> Stream m b concatMapM f (Stream ...) = ... I can get my concatMap to behave nicely and erase all Stream and Step constructors but due to the existential nature of the Stream seeds, they are re-boxed for the inner stream (which is kind-of annoying given that the seed is immediately unboxed again ;-). seq doesn't help here. Otherwise, fusion happens for streams and vectors, so that is ok. But boxing kills performance, criterion says. Do we have s.th. in place that could help here? Currently I could use the vector-concatMap which creates intermediate arrays, my version which has boxed seeds, or hermit but that is too inconvenient for non-ghc savy users. Viele Gruesse, Christian Fusing concatMapM: concatMapM f (SM.Stream ostep t _) = SM.Stream step (Left t) Unknown where step (Left t) = do r <- ostep t case r of SM.Done -> return $ SM.Done SM.Skip t' -> return $ SM.Skip (Left t') SM.Yield a t' -> do s <- f a return $ SM.Skip (Right (s,t')) step (Right (SM.Stream istep s _,t)) = do r <- istep s case r of SM.Done -> return $ SM.Skip (Left t) SM.Skip s' -> return $ SM.Skip (Right (SM.Stream istep s' Unknown,t)) SM.Yield x s' -> return $ SM.Yield x (Right (SM.Stream istep s' Unknown,t)) {-# INLINE [0] step #-} {-# INLINE [1] concatMapM #-} testConcatMapM :: Int -> Int testConcatMapM k = seq k $ U.unId . SM.foldl' (+) 0 . concatMap (\i -> SM.enumFromTo 5 k) $ SM.enumFromTo 3 k {-# NOINLINE testConcatMapM #-} CORE: testConcatMapM testConcatMapM = \ k_aCA -> let! { I# ipv_s1xv ~ _ <- k_aCA } in ### inner loop letrec { $s$wfoldlM'_loop_s29q $s$wfoldlM'_loop_s29q = \ sc_s29i sc1_s29j sc2_s29k -> ### unboxing let! { I# x_a1LA ~ _ <- sc1_s29j } in case tagToEnum# (<=# x_a1LA ipv_s1xv) of _ { False -> $s$wfoldlM'_loop1_s29c sc_s29i sc2_s29k; True -> $s$wfoldlM'_loop_s29q ### reboxing (+# sc_s29i x_a1LA) (I# (+# x_a1LA 1)) sc2_s29k }; ### outer loop $s$wfoldlM'_loop1_s29c $s$wfoldlM'_loop1_s29c = \ sc_s29a sc1_s29b -> case tagToEnum# (<=# sc1_s29b ipv_s1xv) of _ { False -> sc_s29a; True -> case tagToEnum# (<=# 5 ipv_s1xv) of _ { False -> $s$wfoldlM'_loop1_s29c sc_s29a (+# sc1_s29b 1); ### boxed seed (I# 6) True -> $s$wfoldlM'_loop_s29q (+# sc_s29a 5) (I# 6) (+# sc1_s29b 1) } }; } in let! { __DEFAULT ~ ww_s20G <- $s$wfoldlM'_loop1_s29c 0 3 } in I# ww_s20G

2 4

What could be the possible reason of linking errors on "_info" and "_closure"?
by Magicloud Magiclouds 02 Feb '15

02 Feb '15

Hi, I am making a cabal project including a library and a executable using the library. Building the library is fine. But when linking src/main, I got "undefined reference to someFunction1_info" and "someFunction1_closure". -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

1 1

ANN: deepseq-bounded 0.5 -> 0.6
by Andrew Seniuk 25 Jan '15

25 Jan '15

This may affect depending code. Please consult the distro changelog for specific information about how your code might be affected, or better yet, refer to http://www.fremissant.net/deepseq-bounded/transition-5-6-7.html and http://www.fremissant.net/deepseq-bounded/grammar.html This is a transitional version of deepseq-bounded, with stability of the grammar expected in early March for version 0.7. This also causes major version bumps to the seqaid and leaky packages. To update everything, issue cabal update cabal install --reinstall --force-reinstalls seqaid which reinstalls the latest deepseq-bounded in passing. And also if you were to run "seqaid demo" it will use the updated version of leaky, so everything's up to date. The homepage for these projects starts at http://www.fremissant.net/deepseq-bounded-seqaid-leaky.html Kind Regards, Andrew

1 0

Unable to build 7.10.1 RC1 on Jessie
by harry 25 Jan '15

25 Jan '15

I'm trying to build 7.10.1 RC on Debian Jessie. I get an error: configure: error: in `/ghc-7.10.0.20141222/libffi/build/x86_64-unknown-linux-gnu': configure: error: C++ preprocessor "/lib/cpp" fails sanity check config.log shows: configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "libffi" | #define PACKAGE_TARNAME "libffi" | #define PACKAGE_VERSION "3.1" | #define PACKAGE_STRING "libffi 3.1" | #define PACKAGE_BUGREPORT "http://github.com/atgreen/libffi/issues" | #define PACKAGE_URL "" | #define PACKAGE "libffi" | #define VERSION "3.1" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define LT_OBJDIR ".libs/" | /* end confdefs.h. */ | #ifdef __STDC__ | # include <limits.h> | #else | # include <assert.h> | #endif | Syntax error configure:12860: error: in `/ghc-7.10.0.20141222/libffi/build/x86_64-unknown-linux-gnu': configure:12862: error: C++ preprocessor "/lib/cpp" fails sanity check This can be reproduced by running the following commands in the debian:jessie docker image: apt-get update apt-get install ncurses-dev curl gcc ghc make libgmp-dev xz-utils curl http://downloads.haskell.org/~ghc/7.10.1-rc1/ghc-7.10.0.20141222-src.tar.xz | tar xJ cd ghc-* ./configure make Any suggestions for someone who knows nothing about c or cpp? -- View this message in context: http://haskell.1045720.n5.nabble.com/Unable-to-build-7-10-1-RC1-on-Jessie-t… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

3 5