May 2014 - ghc-tickets

Re: [GHC] #6018: Injective type families
by GHC 30 May '14

30 May '14

#6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Injective Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4259 None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by acowley): My intended uses seem to arise quite often, but I've not found one that boils down into a small, self-contained, compelling example. In broad terms, I would like to use type families for decoupling, as hpacheco describes, and to do things like move back and forth between a set of distinct types and singleton Nats. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 30 May '14

30 May '14

#6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Injective Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4259 None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by hpacheco): Is there a current version of the path that works against the current GHC HEAD? The 2-year-old one fails. I can say that I have been trying to define injective type families ever since TypeFamilies were introduced! Especially to define functions like the fmap that MikeIzbicki showed or very simple type-level aliases between different type classes. It also increases modularity. For example, to define the datatypes in different modules, and define an type family aliases in a parent module. {{{ module A where data A = ... data FA = ... module B where data B = ... data FB = ... module Main where import A import B type family F a :: * type instance F A = FA type instance F A = FB }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 30 May '14

30 May '14

#7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by jstolarek): > There really is no alternative to generating them all Yes, I am not questioning that. > What precisely is "above". I don't see a proposed design. I meant storing IDs of calls necessary for desugaring in the extra fields (or extra datatypes) of the constructors of `StmtLR`. Of course this assumes that it is correct to "desugar then typecheck" the arrow do- notation. After reading "A New Notation for Arrows" I feel this should be perfectly OK, just as it is OK for monadic do, but of course that's a layman's perspective. I have a few questions about implementation in `DsArrows` - I think these go to Ross. 1. What is the purpose of the stack created in the desugaring process? 2. How do I read the notation describing each case of `dsCmd`? Eg. the `HsCmdApp` case has this comment: {{{ -- D; ys |-a cmd : (t,stk) --> t' -- D, xs |- exp :: t -- ------------------------ -- D; xs |-a cmd exp : stk --> t' -- -- ---> premap (\ ((xs),stk) -> ((ys),(e,stk))) cmd }}} What is `|-a`, `xs` and `ys`? What is the difference between `:` and `::`? Could you tell me how to read this particular comment? I should then be able to understand all the others. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 30 May '14

30 May '14

#7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): Well in principle with rebindable syntax, each of those calls to `>>>` at different types (I assume they are at different types?) could in principle be overloaded a different way. So * There really is no alternative to generating them all * I really don't know what sort of error message you'd generate for the user if one of the calls to `>>>` failed but the others didn't, say. Before going further I think we need help from Ross, to see if the "thought experiment of desugar and then typecheck" makes sense for arrows. We MUST give a clear story to the programmer of what will type check and what will not. We have that for rebindable syntax and do-notation. I don't know what the story is for rebindable syntax and arrow notation. Until we know that we can't implement anything. > What do you think about the design I describe above? What precisely is "above". I don't see a proposed design. We really need help from Ross here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 30 May '14

30 May '14

#7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by jstolarek): > I think the idea would be that each construct becomes decorated with the overloaded operations necessary to desugar it. Technically this is simple but I feel the resulting design will be inelegant. We use `StmtLR` datatype to represent both the monadic and arrow do-notation. This means that desugaring `BindStmt` inside a monadic `do` requires calls to `>>=` and `fail` ([https://github.com/ghc/ghc/blob/master/compiler/deSugar/DsExpr.lhs#L765 here]), whereas desugaring the same `BindStmt` inside the arrow `do` requires a call to `first`, two different calls to `>>>` and two different calls to `arr` ([https://github.com/ghc/ghc/blob/master/compiler/deSugar/DsArrows.lhs#L838 here]). Adding five extra fields to `BindStmt` feels like a lot of unnecessary noise. Perhaps creating helper datatypes to store these extra identifiers would be better? But then every (or almost every) constructor of `StmtLR` would require such extra datatype. I don't yet see a clean solution. Augmenting `HsCmd` with this extra information seems relatively simple, with `HsCmdCase` being the only tricky case. (It reuses a call to `(|||)` in every branch of a case ([https://github.com/ghc/ghc/blob/master/compiler/deSugar/DsArrows.lhs#L555 here]), which means we need to generate a whole list of new identifiers.) What do you think about the design I describe above? Is it acceptable? Janek -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9153: TcCoercible test is failing with context reduction stack overflow
by GHC 30 May '14

30 May '14

#9153: TcCoercible test is failing with context reduction stack overflow ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Test Suite | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Here is the error: {{{ TcCoercible.hs:62:12: Context reduction stack overflow; size = 21 Use -fcontext-stack=N to increase stack size to N Coercible Int Int In the expression: coerce In the first argument of ‘print’, namely ‘(coerce $ (FixEither (Left age) :: FixEither Age) :: Either Int (FixEither Int))’ In a stmt of a 'do' block: print (coerce $ (FixEither (Left age) :: FixEither Age) :: Either Int (FixEither Int)) }}} I do not know enough to know if bumping the stack size is correct. Additionally, when run as GHCi I get: {{{ =====> TcCoercible(ghci) 2784 of 3970 [0, 7, 0] cd ./typecheck/should_run && '/home/hs01/ezyang/ghc-validate/inplace/bin /ghc-stage2' -fforce-re comp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history Tc Coercible.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS <TcCoercible.genscript 1>TcCo ercible.interp.stdout 2>TcCoercible.interp.stderr Actual stderr output differs from expected: --- /dev/null 2014-02-15 17:35:19.578872448 -0800 +++ ./typecheck/should_run/TcCoercible.run.stderr 2014-05-29 16:27:30.476701835 -0700 @@ -0,0 +1,2 @@ + +TcCoercible:7:30: Not in scope: ‘Main.main’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9153> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5916: runST isn't free
by GHC 29 May '14

29 May '14

#5916: runST isn't free -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by WrenThornton): * cc: winterkoninkje@… (removed) * cc: wren@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5916#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5916: runST isn't free
by GHC 29 May '14

29 May '14

#5916: runST isn't free -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by WrenThornton): * cc: winterkoninkje@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5916#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 29 May '14

29 May '14

#7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): Yes, I think if we made the change suggested here, arrow notation would become rebindable. I think the idea would be that each construct becomes decorated with the overloaded operations necessary to desugar it. Indeed, in the case of monad syntax, the effect is exactly as if you first desugared and then typechecked. For example `x <- e; rest` desugars into something like `e >>= \x -> rest`. So to typecheck `x <- e` (a `BindStmt`), we look up `>>=`, instantiate its type, unify `e`'s type with the first argument type of `>>=`, and so on. We hang onto the instantiated `>>=` in the typechecked `BindStmt`. The idea is to do the same for arrows, but I have little idea of how hard it is. But the thought experiment of first desugaring and then type checking may be an instructive one. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9152: internal error: scavenge_stack: weird activation record found on stack
by GHC 29 May '14

29 May '14

#9152: internal error: scavenge_stack: weird activation record found on stack ----------------------------------+--------------------------------- Reporter: mjo | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- This is a semi-reproducible error that shows up in the test suite for http://hackage.haskell.org/package/htsn-import. You have to run the test suite a few times, but it does crash regularly. Steps to reproduce: {{{ $ ghc --make -O2 -o setup Setup.hs $ ./setup configure --user --enable-tests $ ./setup build $ ./setup test testsuite }}} If that doesn't crash, `./setup test testsuite` can be re-run until it does. Sample crash: {{{ $ ./setup test testsuite Running 1 test suites... Test suite testsuite: RUNNING... All tests AutoRacingSchedule tests cascading delete tests deleting auto_racing_schedules deletes its children: OK deleting auto_racing_schedules deletes its children (miles track length): OK pickle-unpickle tests pickle composed with unpickle is the identity: OK pickle composed with unpickle is the identity (miles track length): OK unpickle tests unpickling succeeds: OK unpickling succeeds (non-int team_id): OK Heartbeat tests pickle composed with unpickle is the identity: OK unpickling succeeds: OK Injuries tests deleting an injuries deletes its children: OK pickle composed with unpickle is the identity: OK unpickling succeeds: OK InjuriesDetail tests cascading delete tests delete of injuries_detail deletes its children: OK delete of injuries_detail deletes its children (non-int team_id): OK pickle-unpickle tests pickle composed with unpickle is the identity: OK pickle composed with unpickle is the identity (non-int team_id): OK unpickle tests unpickling succeeds: OK unpickling succeeds (non-int team_id): OK News tests news fields get correct database names: OK cascading delete tests deleting news deletes its children: OK pickle-unpickle tests pickle composed with unpickle is the identity: OK pickle composed with unpickle is the identity (with Editor): OK unpickle tests unpickling succeeds: OK unpickling succeeds (with Editor): OK Odds tests cascading delete tests deleting odds deletes its children: OK deleting odds deletes its children (non-int team_id): OK deleting odds deleted its children (positive(+) line): OK deleting odds deleted its children (large file): OK pickle-unpickle tests pickle composed with unpickle is the identity: OK pickle composed with unpickle is the identity (non-int team_id): OK pickle composed with unpickle is the identity (positive(+) line): OK pickle composed with unpickle is the identity (large file): testsuite: internal error: scavenge_stack: weird activation record found on stack: 415597384 (GHC version 7.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Test suite testsuite: FAIL Test suite logged to: dist/test/htsn-import-0.0.5-testsuite.log 0 of 1 test suites (0 of 1 test cases) passed. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9152> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1