- Glasgow-haskell-users

Building GHC on NetBSD/amd64
by iquiw 30 Jul '12

30 Jul '12

Hi, I am trying to build GHC on NetBSD/amd64. First, I built GHC-6.12.3 by porting from OpenBSD/amd64. After that, trying to build several versions (6.12.3, 7.0.4, 7.4.2) of GHC by the stage2 compiler. Build itself succeeded and compiling by the ghc seems no problem so far. However, ghci (all versions) crashes always by segmentation fault. --------------------------------------------------------------------- $ ghci GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. zsh: segmentation fault (core dumped) /usr/local/ghc-7.4.2/bin/ghci --------------------------------------------------------------------- backtrace by gdb shows only "s2xW_info ()". ktrace (kernel trace) output is as follows. --------------------------------------------------------------------- 4494 1 ghc CALL __sigprocmask14(3,0x7f7fffff49e0,0) 4494 1 ghc RET __sigprocmask14 0 4494 1 ghc CALL _lwp_self 4494 1 ghc RET _lwp_self 1 4494 1 ghc CALL __sigprocmask14(1,0x7f7fffff4970,0x7f7fffff49e0) 4494 1 ghc RET __sigprocmask14 0 4494 1 ghc CALL __sigprocmask14(3,0x7f7fffff49e0,0) 4494 1 ghc RET __sigprocmask14 0 4494 1 ghc CALL issetugid 4494 1 ghc RET issetugid 0 4494 1 ghc PSIG SIGSEGV SIG_DFL: code=SEGV_MAPERR, addr=0xfffffffff610bfa5, trap=6) 4494 2 ghc RET __kevent50 -1 errno 4 Interrupted system call 4494 3 ghc RET ___lwp_park50 -1 errno 4 Interrupted system call 4494 1 ghc NAMI "ghc.core" --------------------------------------------------------------------- What should I check next? Thanks in advance.

2 1

Simplifying Core using GHC API
by Ranjit Jhala 30 Jul '12

30 Jul '12

Hi all, can anyone point me to the GHC API functions that I can use to trigger the various inlining simplifications? (i.e. to get the inlined CoreExprs that one gets with the -ddump-simpl flag?) Many thanks in advance!, Ranjit Jhala.

2 2

Access to the Parse Tree for Expressions
by Simon Fowler 30 Jul '12

30 Jul '12

Dear all, I'm currently working on a project which would benefit from access to the parse tree - ideally, we would like to deconstruct an expression into its constituent types. Currently we are using the exprType function to return the type of an expression, but this is limited as it only works for one 'level', per se. An example would be as follows. Currently, if we were to type in "map", we would be given a result of type Type, which we could further deconstruct into the various subtypes, as so: map :: (a -> b) -> [a] -> [b] split into: (a -> b) [a] [b] This is sufficient for the basics of the project at the moment, but ideally, we would like to use the parse tree to analyse the structure of expressions and thereby the types of the corresponding sub-expressions. Take "foldr drop" for example; we can determine the different types for the different functions with exprType: foldr :: (a -> b -> b) -> b -> [a] -> [b] drop :: Int -> [c] -> [c] Now we can call exprType on the application "foldr drop": foldr drop :: (Int -> [c] -> [c]) -> [c] -> [Int] -> [c] which would be split, according to our current code, into: arg1: (Int -> [c] -> [c]) arg2: [c] arg3: [Int] result: [c] The problem here is that we are unable to separate the "drop" from the "foldr". The project we are working on involves composing and decomposing expressions, and it is important that we can decompose the type of "foldr drop" into the types of the sub-expressions "foldr" and "drop" recursively. Ideally, we would like to construct a data structure which is much more akin to a parse tree with type annotations, in this case: PTreeApp (PTreeExpr "foldr" [| (a -> b -> b) -> b -> [a] -> [b] |]) (PTreeExpr "drop" [| Int -> [c] -> [c] |]) [| (Int -> [c] -> [c]) -> [c] -> [Int] -> [c] |] where the types in semantic brackets are a structural representation (e.g. TypeRep.Type) of the given types. Looking at the code of exprType, a call is firstly made to hscTcExpr, which in turn makes a call to hscParseStmt to return the parse tree. This would seem to provide the functionality that we would require, in that it would give access to a type-checkable parsed statement, but it doesn't seem to be exported by HscMain. Is there another function, which is accessible through the API, that would support this or something similar? I am far from an expert using the GHC API, so apologies if I am doing something grossly wrong or have missed something blatantly obvious. Thank you for taking the time to read this. Kind regards, Simon

2 1

API function to check whether one type fits "in" another
by "Philip K. F. Hölzenspies" 23 Jul '12

23 Jul '12

L.S., I sent this to the cvs-ghc list, but was - correctly - redirected here. We're trying to write an alternative interactive front-end (alternative to ghci). This front-end is very type-driven; terms are composed not as characters on a prompt, but as applications of terms to terms. At every application of a term to another, we want to check whether the application is well typed and what type variables would have to change. Suppose I want to build the term flip fmap (+) :: Num n => ((n -> n) -> b) -> n -> b In our front-end, however, we do not need the flip; we leave unfilled holes with their type annotated, so the above would really look like this (where [[ and ]] denote a hole): fmap [[ (n -> n) -> b ]] (+) :: Num n => n -> b We start this off by asking for the types of these separate things, using GHC.exprType, giving: fmap: ForAllTy f (ForAllTy a (ForAllTy b (FunTy (TyConApp GHC.Base.Functor [TyVarTy f]) (FunTy (FunTy (TyVarTy a) (TyVarTy b)) (FunTy (AppTy (TyVarTy f) (TyVarTy a)) (AppTy (TyVarTy f) (TyVarTy b))))))) (+): ForAllTy a (FunTy (TyConApp GHC.Num.Num [TyVarTy a]) (FunTy (TyVarTy a) (FunTy (TyVarTy a) (TyVarTy a)))) (Note that 'Var' things are pretty printed to just show their name, whereas all the constructors of Type are displayed using show.) The thing that we really want to ask the GHC-API is whether (+) 'fits into' the second argument-hole of fmap, i.e. we want to know whether (type of +) ForAllTy a (FunTy (TyConApp GHC.Num.Num [TyVarTy a]) (FunTy (TyVarTy a) (FunTy (TyVarTy a) (TyVarTy a)))) fits into (type of second argument of fmap) ForAllTy f (ForAllTy a (FunTy (TyConApp GHC.Base.Functor [TyVarTy f]) (AppTy (TyVarTy f) (TyVarTy a)))) What I'm looking for is a function fitsInto :: TermType -> HoleType -> Maybe [(TyVar,Type)] I have found many functions in TcUnify / Unify / TcMatches that look somewhat like this, but in all cases they required extra arguments. When these extra arguments are filled with arbitrary values, the result is always Nothing or some sort of panic. Any pointers would be truly welcome. Regards, Philip

4 6

Why GHC doesn't warn about LHS nullary-constructor pattern bindings?
by Herbert Valerio Riedel 19 Jul '12

19 Jul '12

Hello, Recently, I was a bit suprised that GHC didn't warn about useless `where` definitions such as the following when using `-Wall` (and I couldn't find a respective warning GHC CLI flag which would have enabled reporting a warning in this case -- unless I missed it) module Foo where foo :: Int -> Int foo n = n + 1 where Nothing = Just n ...wouldn't it be a sensible thing for GHC to warn in such cases (i.e. when the LHS of a pattern binding is a nullary constructor), or is there a useful application for this construct? (In my original case, I ended up with such a "dead" construct after some "unsound" code refactoring, and it would have helped me catch my error earlier, if GHC would have pointed out that somethings fishy with my code)

4 3

Re: Call to arms: lambda-case is stuck and needs your help (fwd)
by Henning Thielemann 19 Jul '12

19 Jul '12

I want to vote, too. I am ok with all of case of \case \of \case of For me single arguments are enough. We already have this restriction for 'case' and I can work around it simply by wrapping arguments in pairs temporarily (cf. curry $ \case ...). I vote against LambdaIf, since if-then-else is already unnecessary and can be written by ifThenElse, and LambdaIf is just ifThenElse with different parameter order. I vote against MultiCaseIf since it can be simply achieved by ifThenElse b1 a1 $ ifThenElse b2 a2 $ ifThenElse b3 a3 $ a4 http://www.haskell.org/haskellwiki/Case

1 0

Occasional segfault in GHCi w/ 7.4.1-rc1 and 64bit OS X
by austin seipp 17 Jul '12

17 Jul '12

Hello GHC hackers, I have been trying the recent 7.4.1-rc1 release on my OSX Snow Leopard machine. I am using the 64bit OSX .tar.bz. I used virthualenv/hsenv to set up a virtual environment to test packages with the RC, but I discovered that GHCi seems to segfault somewhat randomly when invoked. I cannot reproduce this problem with 7.0.4 (64bit,) 7.2.2 (64bit,) or 7.5.20111223 (also 64bit.) I have invoked GHCi probably a hundred times each, and have never had it crash. I can crash the RC fairly reliably however. I looked at the shell scripts that invoke GHC and ran GDB with the proper arguments. I got a backtrace like so: $ gdb /Users/a/vh-741-rc1_2/.hsenv/ghc/lib/ghc-7.4.0.20111219/ghc GNU gdb 6.3.50-20050815 (Apple version gdb-1518) (Sat Feb 12 02:52:12 UTC 2011) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .... done warning: Could not find object file "/Users/ian/zz64/ghc-7.4.0.20111219/rts/dist/build/libHSrts_thr.a(ffi64.o)" - no debug information available for "../src/x86/ffi64.c". warning: Could not find object file "/Users/ian/zz64/ghc-7.4.0.20111219/rts/dist/build/libHSrts_thr.a(prep_cif.o)" - no debug information available for "../src/prep_cif.c". warning: Could not find object file "/Users/ian/zz64/ghc-7.4.0.20111219/rts/dist/build/libHSrts_thr.a(types.o)" - no debug information available for "../src/types.c". (gdb) r -B/Users/a/vh-741-rc1_2/.hsenv/ghc/lib/ghc-7.4.0.20111219 --interactive Starting program: /Users/a/vh-741-rc1_2/.hsenv/ghc/lib/ghc-7.4.0.20111219/ghc -B/Users/a/vh-741-rc1_2/.hsenv/ghc/lib/ghc-7.4.0.20111219 --interactive Reading symbols for shared libraries + done GHCi, version 7.4.0.20111219: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000ae21cf68 0x00000001ae2060da in evacuate1 () (gdb) bt #0 0x00000001ae2060da in evacuate1 () #1 0x00000001ae20b868 in scavenge_block1 () Previous frame inner to this frame (gdb could not unwind past this frame) (gdb) So it looks like a GC bug at first glance, but I haven't done rigorous investigation. Again this doesn't happen every time - probably 1/3 the time it crashes, the other 2/3 the time it seems to work fine. This naturally also affects `runghc`. Is this a known issue? Or should I file a bug and investigate further? Perhaps something forgot to get something merged into the 7.4 branch? -- Regards, Austin

7 8

Call to arms: lambda-case is stuck and needs your help
by Mikhail Vorozhtsov 17 Jul '12

17 Jul '12

Hi. After 21 months of occasional arguing the lambda-case proposal(s) is in danger of being buried under its own trac ticket comments. We need fresh blood to finally reach an agreement on the syntax. Read the wiki page[1], take a look at the ticket[2], vote and comment on the proposals! P.S. I'm CC-ing Cafe to attract more people, but please keep the discussion to the GHC Users list. [1] http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMatching [2] http://hackage.haskell.org/trac/ghc/ticket/4359

27 72

"containing" memory-consuming computations
by Herbert Valerio Riedel 16 Jul '12

16 Jul '12

Hello GHC Devs, One issue that's been bothering me when writing Haskell programs meant to be long-running processes performing computations on external input-data in terms of an event/request-loop (think web-services, SQL-servers, or REPLs), that it is desirable to be able to limit resource-usage and be able to "contain" the effects of computations which exhausts the resource-limits (i.e. w/o crashing and burning the whole process) For the time-dimension, I'm already using functions such as System.Timeout.timeout which I can use to make sure that even a (forced) pure computation doesn't require (significantly) more wall-clock time than I expect it to. But I'm missing a similar facility for constraining the space-dimension. In some other languages such as C, I have (more or less) the ability to check for /local/ out-of-memory conditions (e.g. by checking the return value of e.g. malloc(3) for heap-allocations, or by handling an OOM exception), rollback the computation, and be able to skip to the next computation request (which hopefully requires less memory...) So, is there already any such facility provided by the GHC Platform I've missed so far? ...and if not, would such a memory-limiting facility be reconcilable with the GHC RTS architecture? Cheers, hvr --

6 8

“Ambiguous type variable in the constraint” error in rewrite rule
by Tsuyoshi Ito 16 Jul '12

16 Jul '12

Hello, Why does GHC 7.4.1 reject the rewrite rule in the following code? > module Test where > > import Data.Monoid > import Control.Monad.Writer.Strict > > f :: Monad m => a -> m a > f = return > > g :: Monoid w => a -> Writer w a > g = return > > {-# RULES > "f->g" f = g > #-} On the line containing the rewrite rule, GHC shows the following error message: Test.hs:13:12: Ambiguous type variable `w0' in the constraint: (Monoid w0) arising from a use of `g' Probable fix: add a type signature that fixes these type variable(s) In the expression: g When checking the transformation rule "f->g" Interestingly, the code compiles if the rewrite rule is replaced with the following SPECIALIZE pragma: > {-# SPECIALIZE f :: Monoid w => a -> Writer w a #-} I find this strange because if I am not mistaken, this specialization is handled by using a rewrite rule of the same type as the one which GHC rejects. The following ticket might be related, but I am not sure: Subclass Specialization in Rewrite Rules http://hackage.haskell.org/trac/ghc/ticket/6102 Best regards, Tsuyoshi

2 3