May 2018 - ghc-tickets

[GHC] Batch modify: #13002
by GHC 29 May '18

29 May '18

Batch modification to #13002 by bgamari: milestone to 8.6.1 Comment: Ticket retargeted after milestone closed -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=13002> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9438: panic: loading archives not supported
by GHC 29 May '18

29 May '18

#9438: panic: loading archives not supported ----------------------------------+---------------------------------- Reporter: egl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+---------------------------------- Running {{{ ghci -L/opt/local/lib -latlas }}} eventually leads to {{{ Loading object (static archive) /opt/local/lib/libatlas.a ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading archives not supported Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This looks similar to 8164 and 4828, which are marked closed. Mac OSX 10.9.4 Xcode 5.1.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9438> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14032: Can't splice TH quote with infix declaration for name in two different namespaces
by GHC 29 May '18

29 May '18

#14032: Can't splice TH quote with infix declaration for name in two different namespaces -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Spun off from #13799 (and https://ghc.haskell.org/trac/ghc/ticket/13054#comment:2) This code compiles: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeOperators #-} infix 5 :*: data a :*: b = a :*: b }}} But this code does not: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeOperators #-} $([d| infix 5 :*: data a :*: b = a :*: b |]) }}} {{{ $ /opt/ghc/8.2.1/bin/ghc -ddump-splices Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Bug.hs:(4,3)-(6,6): Splicing declarations [d| infix 5 :*:_anM, :*:_anL data a_anN :*:_anL b_anO = a_anN :*:_anM b_anO |] ======> infix 5 :*:_a3IL infix 5 :*:_a3IK data (:*:_a3IK) a_a3IM b_a3IN = a_a3IM :*:_a3IL b_a3IN Bug.hs:4:3: error: Multiple fixity declarations for ‘:*:_a3IL’ also at Bug.hs:(4,3)-(6,6) | 4 | $([d| infix 5 :*: | ^^^^^^^^^^^^^^^... }}} Inspecting the `-ddump-splices` output reveals why: when `infix 5 :*:` is renamed, because `:*:` refers to two different names in both the value and type namespaces, it actually gets renamed to `infix 5 :*:_anM, :*:_anL`, where `:*:_anM` and `:*:_anL` are the same name with different uniques. Normally, this isn't a problem, since feeding `infix 5 :*:_anM, :*:_anL` to the typechecker works fine. However, when it's spliced in via Template Haskell, it gets fed back into the renamer, where it believes that `:*:_anM` and `:*:_anL` are duplicate names, causing the error. Really, this is just a symptom of the fact that infix declarations are insufficiently powerful to encode information for identical names in different namespaces. But until GHC gains this ability, we need to find some workaround for this problem. My hunch is that we'll need to give GHC the power to recognize these sorts of duplicate fixity declarations in `Convert` and only emit one actual fixity declaration per set of duplicates. (Disclaimer: I haven't worked out all the fiddly details yet.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14032> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13126: Support for hexadecimal floats
by GHC 29 May '18

29 May '18

#13126: Support for hexadecimal floats -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, Haskell only allows writing floating-point numbers in the decimal format. Unfortunately, writing floats in decimal/scientific format is not always the best option, due to loss of precision. As an alternative, there's the so called "hexadecimal floating point" format, described in p57-58 of: http://www.open- std.org/jtc1/sc22/wg14/www/docs/n1256.pdf The format is rather simple, unambiguous, and relatively easy to implement. And it's been around for about 10 years by now. It would be nice if the Haskell standard was changed to include such literals. But in the meantime, perhaps GHC can support such literals via a pragma, such as `LANGUAGE HexadecimalFloats` or similar. A corresponding pretty printer (similar to C's %a specifier) is also needed; which should go into the standard `Numerics` module. Such a function can be called `showHFloat` to accompany the similarly named functions for rendering float values. A reference implementation can be given by template-Haskell splicing, and indeed the hackage package FloatingHex (http://hackage.haskell.org/package/FloatingHex) provides both a quasi- quoter for such literals, and the pretty printer `showHFloat.` Unfortunately, this solution is less than satisfactory as it relies on the rather heavy mechanism for quasi-quotes, requires an extra library dependency, a pragma (`QuasiQuotes`), and the import and dependency of a hackage package, which sounds a lot for just being able to write floats precisely! Furthermore, Tempate Haskell has an issue with the storage of floats (https://ghc.haskell.org/trac/ghc/ticket/13124) which makes the library solution less than ideal in overflow cases. (Long story short: Template- Haskell stores floating literals as rationals, and thus has no reliable way of representing floats such as NaN, Infinity, and especially negative- zero.) Numeric programming is important, especially in this new era of HPC, and many-core architectures tuned for crunching floating-point data seamlessly. While this is admittedly a minor step, I think it'll be a positive addition to GHC from a maturity perspective, and that of matching/leading other languages out there. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14602: Implement the pattern synonym construction function signatures proposal
by GHC 29 May '18

29 May '18

#14602: Implement the pattern synonym construction function signatures proposal -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0005 -bidir-constr-sigs.rst The pattern synonym construction function signatures proposal] has been accepted and should be implemented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14602> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 29 May '18

29 May '18

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: deriving, | newcomer, GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_run/T7401, | deriving/should_run/T7401_fail Blocked By: | Blocking: Related Tickets: #10577, #13117 | Differential Rev(s): Phab:D4047 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: deriving, newcomer => deriving, newcomer, GHCProposal -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:55> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10843: Allow do blocks without dollar signs as arguments
by GHC 29 May '18

29 May '18

#10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I would like the following to be valid Haskell code: {{{#!hs main = when True do putStrLn "Hello!" }}} Instead of requiring a dollar sign before the "do". This would parse as {{{#!hs main = when True (do putStrLn "Hello!") }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10843> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

[GHC] #9793: Some as-patterns could be accepted in pattern synonyms
by GHC 29 May '18

29 May '18

#9793: Some as-patterns could be accepted in pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: pattern synonyms | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Easy (less than 1 | None/Unknown hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Currently all as-patterns are rejected in pattern synonym definitions, to avoid situations like {{{ pattern P x y <- x@(y:_) }}} since there's no valid reason to be able to then write something like {{{ f [True] False = ... }}} this would just lead to confusion. However, I think we could accept as-patterns where the body of the as- pattern doesn't contain any variable bindings that are accessible via the pattern synonym. In other words, this should be OK: {{{ pattern P x <- x@(y:_) }}} since it's exactly equivalent to {{{ pattern P x <- x@(_:_) }}} which I don't think is as confusing as the other example. I haven't really made up my mind yet if these should be bidirectional; but they certainly could be, by just ignoring the body of the as-pattern in the wrapper; so the following two would be equivalent: {{{ pattern P1 x = [x@(y:_)] pattern P2 x <- [x@(y:_)] where P2 x = [x] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9793> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #15194: Consider a QSem variant that can hold back resources
by GHC 29 May '18

29 May '18

#15194: Consider a QSem variant that can hold back resources -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `QSem` always wakes up threads when resources become available. This leads to unavoidable contention between waiting and signaling threads. If, however, a quantity semaphore is allowed to hold some resources back, then these can be decoupled. One `MVar` holds an immediately available resource quantity or a list of threads waiting to be enqueued. The other holds a reserved resource quantity or a FIFO queue of threads. The only non-exceptional time an operation needs both `MVar`s is when signaling exceeds the reserve capacity. In that case, the reserve is dumped into the available bucket, listed threads are enqueued, and threads in the queue are woken up until resources or threads are exhausted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15194> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable
by GHC 29 May '18

29 May '18

#4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I haven't looked in great details but that seems like a reasonable approach to me. I'd say go ahead and give it a try! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4806#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0