September 2014 - ghc-tickets

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 15 Sep '14

15 Sep '14

#7828: RebindableSyntax and Arrow -------------------------------------+------------------------------------- Reporter: | Owner: jstolarek AlessandroVermeulen | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #1537, #3613 Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D72 | -------------------------------------+------------------------------------- Comment (by simonpj): See also [http://blog.spacekitteh.moe/posts/new-monoidal-cats.html Sophie Taylor's proposal] about monoidal category classes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 15 Sep '14

15 Sep '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): > what's wrong with exponential time here? Compilation times. If a type family takes a single argument then obviously there is only one possible injectivity condition ("result -> a"). For two arguments there are 5 possible injectivity conditions. For 3 this number jumps to 19. 4 arguments => 65 combinations. 5 arguments => 211 combinations. 6 arguments => 665 combinations. Let's assume (for illustrative purposes) that verifying (ie. attempting to infer) a single injectivity condition for a type family takes 0.01s. Under such assumptions inferring all possible injectivity conditions for a type family with 6 arguments will take ~6.5s. We can't do that. > Is there any patch which would allow me to use injective type families in current GHC? No. But if all goes well all this discussion here will culminate with such a patch :-) In the meantime, if you have any motivating use cases that require injectivity to work please share them if you can. This would be most helpful. I've spent last several days thinking intensely about the design and made some progress. Hopefully, I'll incorporate my notes into the wiki page by the end of the week. Will get back with some ideas and proposals once this happens. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:64> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4426: Simplify the rules for implicit quantification
by GHC 14 Sep '14

14 Sep '14

#4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: low | Version: 6.12.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7880 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D211 | -------------------------------------+------------------------------------- Changes (by monoidal): * status: infoneeded => patch * differential: => Phab:D211 Comment: The patch (ghc+haddock) is ready for review in Phabricator, and the change to haskeline was merged. There are only minor changes since the previous patch - I've clarified the documentation and updated TH testcases that were created in the meantime. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4426#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries
by GHC 14 Sep '14

14 Sep '14

#6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9421 | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by cetu86): Inside your cross toolchain there is a directory that is literally called "sysroot". Inside it you'll find your standard unix root. Looks like this {{{ . └── arm-unknown-linux-gnueabi ├── arm-unknown-linux-gnueabi │ └── sysroot │ ├── bin │ ├── etc │ ├── include │ ├── lib │ ├── sbin │ ├── share │ ├── usr │ │ ├── bin │ │ ├── include --> ncurses.h, curses.h go here │ │ ├── lib --> libncurses.a goes here │ └── var }}} If you use ".../sysroot/usr" as prefix everything should go fine. Except ncurses puts its header files in a subdirectory "include/ncurses" but ghc includes the header file as {{{ #include <ncurses.h> }}} not as {{{ #include <ncurses/ncurses.h> }}} What it did was move all files in the ncurses directory one up and create a symlink for compatibility. (in case I'd later install something that expects ncurses in its original place) Like this: {{{ cd sysroot/usr/inlude/ncurses mv * .. cd .. rmdir ncurses ln -s . ncurses }}} Now I have {{{ daniel@inferno:~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux- gnueabi/sysroot/usr/include/ > ls -l ncurs* curs* -rw-r--r-- 1 daniel users 6590 9. Sep 12:38 cursesapp.h -rw-r--r-- 1 daniel users 27646 9. Sep 12:38 cursesf.h -rw-r--r-- 1 daniel users 76252 9. Sep 12:38 curses.h -rw-r--r-- 1 daniel users 19518 9. Sep 12:38 cursesm.h -rw-r--r-- 1 daniel users 8489 9. Sep 12:38 cursesp.h -rw-r--r-- 1 daniel users 49280 9. Sep 12:38 cursesw.h -rw-r--r-- 1 daniel users 7312 9. Sep 12:38 cursslk.h lrwxrwxrwx 1 daniel users 1 9. Sep 14:19 ncurses -> . -rw-r--r-- 1 daniel users 3925 9. Sep 12:38 ncurses_dll.h lrwxrwxrwx 1 daniel users 8 9. Sep 12:38 ncurses.h -> curses.h }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6086#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9585: Note about semantics of (!!) is not specific enough, if it's correct
by GHC 12 Sep '14

12 Sep '14

#9585: Note about semantics of (!!) is not specific enough, if it's correct -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | Documentation bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The definition of `(!!)` in `GHC.List`, copied below, has a vague note about semantics for the Prelude and HBC versions being different. I can't see the difference myself. If there really is a difference, the details should be in the comment. {{{#!hs -- | List index (subscript) operator, starting from 0. -- It is an instance of the more general 'Data.List.genericIndex', -- which takes an index of any integral type. (!!) :: [a] -> Int -> a #ifdef USE_REPORT_PRELUDE xs !! n | n < 0 = error "Prelude.!!: negative index" [] !! _ = error "Prelude.!!: index too large" (x:_) !! 0 = x (_:xs) !! n = xs !! (n-1) #else -- HBC version (stolen), then unboxified -- The semantics is not quite the same for error conditions -- in the more efficient version. -- xs !! (I# n0) | isTrue# (n0 <# 0#) = error "Prelude.(!!): negative index\n" | otherwise = sub xs n0 where sub :: [a] -> Int# -> a sub [] _ = error "Prelude.(!!): index too large\n" sub (y:ys) n = if isTrue# (n ==# 0#) then y else sub ys (n -# 1#) #endif }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9585> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries
by GHC 12 Sep '14

12 Sep '14

#6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9421 | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by jpmasseria): Replying to [comment:23 cetu86]: Thanks for the continued help. I'm still stuck where my GHC build doesn't find ncurses. I have done the following (my main issue is that I don't really understand where I need to "install" my cross compiled version of ncurses. {{{ wget ftp.de.debian.org/debian/pool/main/n/ncurses/ncurses_5.9.orig.tar.gz tar xf ncurses_5.9.orig.tar.gz cd ncurses-5.9/ ./configure --target=arm-linux-gnueabihf --with-gcc=arm-linux- gnueabihf-gcc --target=arm-linux-gnueabihf --prefix=/home/johnma/arm- linux-gnueabihf make && make install }}} As I understand it this placed the cross compiled `ncurses` into my directory `/home/johnma/arm-linux/gnueabihf` I then tried to build GHC using this as follows: {{{ cd ../ghc/ ./configure --target=arm-linux-gnueabihf --enable-unregisterised --with-gcc=`which arm-linux-gnueabihf-gcc` --with-nm=/usr/bin/nm --with- sysroot=/home/johnma/arm-linux-gnueabihf make -j2 }}} Needless to say that achieved the same ncurses not found error. Again, my confusion is how I tell the GHC build to find this ncurses. Thank you! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6086#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 12 Sep '14

12 Sep '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by danilo2): Hello! Is there any patch which would allow me to use injective type families in current GHC? I saw on the top of this page, that a patch was provided, but about 2 years ago - are there any working implementations? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:63> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7567: invalidateModSummaryCache throws exception if ms_hs_date is 0
by GHC 12 Sep '14

12 Sep '14

#7567: invalidateModSummaryCache throws exception if ms_hs_date is 0 -------------------------------------+------------------------------------- Reporter: edsko | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: => thoughtpolice -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7567#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5289: Can't use ghci with a library linked against libstdc++
by GHC 12 Sep '14

12 Sep '14

#5289: Can't use ghci with a library linked against libstdc++ -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHCi crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ihameed): * cc: idhameed@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5289#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9581: Parse error in multiline case expression inside let inside do block
by GHC 11 Sep '14

11 Sep '14

#9581: Parse error in multiline case expression inside let inside do block -------------------------------------+------------------------------------- Reporter: mpopov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{#!hs main = do let x = case 1 of 0 -> False _ -> True print x }}} The above program produces the following error: $ runghc bug.hs bug.hs:3:11: parse error on input ‘->’ Slightly rewritten versions print True as indended: {{{#!hs main = do let x = case 1 of { 0 -> False; _ -> True } print x main = do print $ case 1 of 0 -> False _ -> True }}} I have double-checked that the offending program does not contain mixed tabs and spaces. The same error occurs on my own system (Linux Mint x64, Haskell Platform 2014.2 with GHC 7.83) and in FPComplete's online IDE. I first encountered the error in a program copied verbatim from a Haskell book, so i assume that the syntax is allowed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9581> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1