October 2014 - ghc-tickets

Re: [GHC] #6018: Injective type families
by GHC 22 Oct '14

22 Oct '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: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): > Before we forget it, the big un-implemented piece is checking that the type-family equations are indeed injective. Or is that done now? No, that's not implemented yet - I'm distracted between this and two other GHC projects so I didn't yet have the time :-( -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:96> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 22 Oct '14

22 Oct '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: Phab:D202 | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, we need to look through all the equations. Very like functional dependencies. Before we forget it, the big un-implemented piece is checking that the type-family equations are indeed injective. Or is that done now? I can't see it in Phab. That's the main reason I'm doubtful we'll make 7.10, unless perhaps you have it ready to go. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:95> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 22 Oct '14

22 Oct '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: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): If we're not aiming to get this into 7.10 then I guess there's no rush. Replying to [comment:93 simonpj]: > All I plan to do is add a rule along the lines of > {{{ > [W] F ty1 ~ rhs > [W] F ty2 ~ rhs > ===> add a new constraint (if F is injective) > [D] ty1 ~ ty2 > }}} > very like functional dependencies for type classes. Yes, that's what I meant with my INJFEQFEQ interaction rule in [comment:89 comment 89]: {{{ INJFEQFEQ interact[l] (F \vec{Xi_1} ~ Xi, F \vec{Xi_2} ~ Xi) = (F \vec{Xi_1} ~ Xi, \vec{ Xi_1 ~ Xi_2 }) }}} Sorry if that wasn't clear. (Now I realized that checking whether `F` is injective might be consider a reaction with top-level axiom and thus this should be a reaction rule.) But it seems to me there should be one more rule. Consider this example: {{{#!hs type family F a = r | r -> a where F Char = Bool F Bool = Char F a = a idChar :: (F a ~ Bool) => a -> Char idChar a = a }}} Here we have constraint `F a ~ Bool`. Knowing that `F` is injective and it's RHS is `Bool` we want to deduce that `a` must be `Char`. This one seems more difficult because we have to look through all the equations. My guess would be that when we have to do this before constraint solving (in `TcM` monad?). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:94> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9679: testsuite/.gitignore does not cover some test outputs on Windows
by GHC 21 Oct '14

21 Oct '14

#9679: testsuite/.gitignore does not cover some test outputs on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Some test suite outputs on Windows are not covered by testsuite/.gitignore, polluting the output of 'git status'. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9679> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #1473: isSpace is too slow
by GHC 21 Oct '14

21 Oct '14

#1473: isSpace is too slow -------------------------------------+------------------------------------- Reporter: igloo | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 6.6.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"31571270625a690410b794b7cfe48d866c084e74/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="31571270625a690410b794b7cfe48d866c084e74" Improve isDigit, isSpace, etc. Summary: Make things less branchy; use unsigned comparisons for range checking. Eliminate non-spaces more quickly in common cases in isSpace. Reviewers: ekmett, carter, austin Reviewed By: austin Subscribers: thomie, carter, ezyang, simonmar Differential Revision: https://phabricator.haskell.org/D340 GHC Trac Issues: #1473 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1473#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 21 Oct '14

21 Oct '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: Phab:D202 | -------------------------------------+------------------------------------- Comment (by simonpj): Sure. Take as long as you need. I was offering to do the type inference piece, which seemed to be the bit you are stalled on. So if you do parser, renamer, and typechecking of the `TyCon` declaration, so we have the injectivity info in the `TyCon`, that would do it I think. In practical terms, a branch in a github repo that I can pull and push to would work well. All I plan to do is add a rule along the lines of {{{ [W] F ty1 ~ rhs [W] F ty2 ~ rhs ===> add a new constraint (if F is injective) [D] ty1 ~ ty2 }}} very like functional dependencies for type classes. I'm not sure that there is time to get this implemented, tested etc before the 7.10 freeze, but we'll see. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:93> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9038: Foreign calls don't make their arguments look strict
by GHC 21 Oct '14

21 Oct '14

#9038: Foreign calls don't make their arguments look strict ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Here's a function that takes a `Double` which is always passed to a `foreign import` expecting a `Double#`. Since the value is always unpacked, I'd expect `add3` to be strict in the `Double` argument and thereby avoid some allocation. {{{ add3 :: Distribution -> Double -> Int64 -> State# RealWorld -> (# State# RealWorld, () #) add3 = \ (distrib_a1uw :: Distribution) (val_a1ux :: Double) (n_a1uy :: Int64) (eta_X22 :: State# RealWorld) -> case myThreadId# eta_X22 of _ { (# ipv_i229, ipv1_i22a #) -> case threadStatus# ipv1_i22a ipv_i229 of _ { (# ipv2_i22e, _, ipv4_i22g, _ #) -> case modInt# ipv4_i22g 8 of ww1_i1NM { __DEFAULT -> case distrib_a1uw `cast` (<NTCo:Distribution> :: Distribution ~# Array Stripe) of _ { Array ds2_i22q -> case indexArray# ds2_i22q ww1_i1NM of _ { (# ipv6_i1Nz #) -> case ipv6_i1Nz of _ { Stripe ipv7_s22v ipv8_s22w ipv9_s22x ipv10_s22y -> case {__pkg_ccall main hs_lock Addr# -> State# RealWorld -> (# State# RealWorld #)}_i20J ipv9_s22x ipv2_i22e of _ { (# ds4_i20P #) -> case touch# ipv10_s22y ds4_i20P of s'_i20R { __DEFAULT -> case val_a1ux of _ { D# ds6_d1D8 -> case n_a1uy of _ { I64# ds8_d1Da -> case {__pkg_ccall main hs_distrib_add_n Addr# -> Double# -> Int# -> State# RealWorld -> (# State# RealWorld #)}_d1Dd ipv7_s22v ds6_d1D8 ds8_d1Da s'_i20R of _ { (# ds9_d1Db #) -> case {__pkg_ccall main hs_unlock Addr# -> State# RealWorld -> (# State# RealWorld #)}_i20m ipv9_s22x ds9_d1Db of _ { (# ds10_i20s #) -> case touch# ipv10_s22y ds10_i20s of s'1_i20u { __DEFAULT -> case touch# ipv8_s22w s'1_i20u of s'2_i1YT { __DEFAULT -> (# s'2_i1YT, () #) } } } } } } } } } } } } } } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9038> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9702: Offer a weaker name shadowing warning
by GHC 21 Oct '14

21 Oct '14

#9702: Offer a weaker name shadowing warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: warning, module | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Suppose I have a module {{{#!hs module Survive where import HuntGather flounder = goFishing river where goFishing = ... }}} If the maintainer of `HuntGather` decides to add a `goFishing` function, my module will suddenly get a name shadowing warning, although there is little risk of confusion. So I think it makes a lot of sense to offer, at least, a version that ignores shadowing of *implicitly imported* names, and to use this for `-Wall` instead of the current version. Another step down would be to ignore shadowing of all top-level names, but having three levels of name shadowing warning would be too much trouble by far. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9702> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #6018: Injective type families
by GHC 21 Oct '14

21 Oct '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: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): Can I get some more time before I throw in the towel? Say, until next Thursday? Simon, if you were to start working on this what parts of my implementation need to be finished? Everything up to `SynTyCon` storing a list of `Bool`s? In what form would you like my patch? A differential revision? A branch on github? Do you want my work rebased against latest HEAD? > Decomposition in brief. If you want Maybe a ~ Maybe b then it's enough to prove a ~ b. From a proof of the latter we can get a proof of the former. No more than that. Obviously, this is what we currently have for data types and what we want for injective type families. But from the OutsideIn paper my understanding was that *current* treatment of *type families* is different. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:92> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7942: aarch64 support in ghc
by GHC 21 Oct '14

21 Oct '14

#7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by lukexi): Thanks Carter! I've got one more patch to push up — I implemented the necessary functions from SMP.h in ARM64 ASM while backporting the ARM64 support to 7.8 (as I needed it... though I'm not sure that will be deemed worthy of inclusion in 7.8.4 since it relies on the LLVM 3.5 support) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0