August 2016 - ghc-tickets

[GHC] #8171: Extending ExtendedDefaultRules
by GHC 02 Nov '17

02 Nov '17

#8171: Extending ExtendedDefaultRules ------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The current `ExtendedDefaultRules` is set up in a way that largely prevents it from being used for scenarios beyond what they get used for in GHCi today. It would be great if there was an extra class that could be included in the list of acceptable classes for Rule 3. {{{ class Defaulting a }}} The proposed change would be that Rule 3 under EDR can be be relaxed to: At least one of the classes Ci is numeric, or is `Show`, `Eq`, `Ord` or `Defaulting`. I went with `Defaulting` rather than `Default`, because `Default` is a common class in use across the ecosystem from the `data-default` package, and I wanted to avoid gratuitous fallout. This would permit projects like Shae Erisson's `ghclive` from last year that need to use defaulting to not have to shoe-horn unnecessary `Show` constraints onto functions. Even better would be for that class to be polykinded! That opens up possibilities for expert users to get defaulting to fire on arguments of other kinds, which is impossible under the current EDR. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8171> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9249: Link to "latest" user's guide
by GHC 01 Nov '17

01 Nov '17

#9249: Link to "latest" user's guide ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | 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: | ------------------------------------+------------------------------------- When I search (say, on Google) for a GHC-related bit of documentation, I variously get referred to old manuals. There doesn't seem to a good way for us, the GHC devs, to avoid this. But, perhaps we can include some information in the header of the pages to allow visitors to link to the latest manual, or perhaps to several versions. This header should also include the version number of the GHC that the page is documenting; currently, this info is only in the URL. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9249> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks
by GHC 01 Nov '17

01 Nov '17

#12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8 has a lot of trouble compiling the following program: {{{#!hs module Serialize where data Result a = Success a | Error String {- 80 guards ghc-7.10.3 -O : 0.3s ghc-8.0.1 -O : 1.8s -} instance Functor Result where {-# INLINE fmap #-} fmap | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f | bool = f where bool = undefined f = undefined }}} Here are some timing results, depending on the number of `| bool = f` clauses: {{{ * ghc-8.0.1 N clauses : time (s) 10 : 0.61 20 : 0.78 40 : 1.03 80 : 1.64 160 : 2.83 320 : 5.16 640 : 10.37 1280 : 21.16 * ghc-7.10.3 N clauses : time (s) 10 : 0.33 20 : 0.29 40 : 0.34 80 : 0.30 160 : 0.32 320 : 0.35 640 : 0.48 1280 : 0.80 }}} I think this compile time difference is caused by the `CallStack` changes introduced in GHC 8.0. When I use a version of `undefined` that doesn't have a CallStack, there is no difference in compile time when using GHC 7.10 or GHC 8.0. This is my implementation of `undefined` without `CallStack`: {{{ import GHC.Exception (errorCallException) import GHC.Prim (raise#) import Prelude (Char) error :: [Char] -> a error s = raise# (errorCallException s) undefined :: a undefined = error "undefined without callstack" }}} This is the quick and dirty Python script I used to generate those timing results (ghc version is hardcoded): {{{#!py import os import tempfile import time import subprocess def src(n): return ''' module Test where data Result a = Success a | Error String instance Functor Result where {{-# INLINE fmap #-}} fmap {0} where bool = undefined f = undefined '''.format('\n | bool = f' * n) tempfile = tempfile.mktemp('.hs') print('tempfile = {0}'.format(tempfile)) print('N clauses : time (s)') for i in range(8): n = 10 * 2 ** i with open(tempfile, 'w') as f: f.write(src(n)) f.flush() t0 = time.time() subprocess.call(['ghc-8.0.1', '-v0', '-O', tempfile]) t1 = time.time() print(str(n).ljust(10) + ': %.2f' % (t1 - t0)) os.remove(tempfile) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12150> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #11787: Infer HasCallStack where possible
by GHC 01 Nov '17

01 Nov '17

#11787: Infer HasCallStack where possible -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- Consider {{{ Prelude> :t error error :: GHC.Stack.Types.HasCallStack => [Char] -> a Prelude> :t (\x -> error x) (\x -> error x) :: (?callStack::GHC.Stack.Types.CallStack) => [Char] -> a }}} We would prefer to get the same type for the latter as the former. Moreover, when we execute on #11376 (comment 25), `:t error` will show the more complicated type too. My suggestion: during generalisation, when we see `?callStack::CallStack`, use the built-in type synonym `HasCallStack`. Note that this should only happen if the name used for the implicit parameter is actually `?callstack`. Eric would you like to consider this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11787> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11573: CallStacks show up unexpectedly in type of local binding in GHCi
by GHC 01 Nov '17

01 Nov '17

#11573: CallStacks show up unexpectedly in type of local binding in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Type checker) | 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: -------------------------------------+------------------------------------- It was noticed (in a thread on ghc-devs) that introducing a CallStack- carrying term into the RHS of a let binding in GHCi produces a type which itself carries a callstack. I could be wrong but as far as I know this is a bug: the solver should never introduce a constraint that the user didn't write; it should merely provide an empty callstack in the event that a callstack constraint can't be solved. {{{ Prelude> let myList = [1, 2, 3 :: Integer] Prelude> let myList' = myList ++ undefined Prelude> :t myList myList :: [Integer] Prelude> :t myList' myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11573> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11298: Implicit call stack empty in instance declarations
by GHC 01 Nov '17

01 Nov '17

#11298: Implicit call stack empty in instance declarations -------------------------------------+------------------------------------- Reporter: pikajude | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given the following code: {{{#!hs {-# LANGUAGE ImplicitParams #-} import GHC.Stack class Foo a where foo :: a -> String main = putStrLn $ foo () }}} In GHC 7.11.20151216, the following instances result in no output: {{{#!hs instance Foo () where foo () = prettyCallStack ?loc }}} {{{#!hs fooHelper = prettyCallStack ?loc instance Foo () where foo () = fooHelper }}} Though this one does: {{{#!hs fooHelper () = prettyCallStack ?loc instance Foo () where foo = fooHelper }}} The aforementioned instances all yield output with GHC 7.10.3 (after replacing `prettyCallStack` with `showCallStack`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12143: ApplicativeDo Fails to Desugar 'return True'
by GHC 31 Oct '17

31 Oct '17

#12143: ApplicativeDo Fails to Desugar 'return True' -------------------------------------+------------------------------------- Reporter: MichaelBurge | Owner: Type: bug | Status: new 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: -------------------------------------+------------------------------------- If I bring in a spurious parameter, ApplicativeDo correctly infers Functor. {{{ Prelude> :t \m -> do { x <- m; return True; } \m -> do { x <- m; return True; } :: Functor f => f t -> f Bool Prelude> :t \m -> do { m; return True; } \m -> do { m; return True; } :: Monad m => m a -> m Bool }}} However, without the spurious parameter, ApplicativeDo assumes monad. {{{ Prelude> :t do { return True; } do { return True; } :: Monad m => m Bool }}} The first block in particular shows two examples that seem inconsistent when placed next to each other. It seems like if 'x' is unused, then 'x <- m' and 'm' should be equivalent. I would expect all of these to desugar to Functor or Applicative. And maybe 'return True' should be Monad, but 'do { return True; }' should be Applicative? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12143> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4
by GHC 20 Oct '17

20 Oct '17

#12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, git clone (commit dfe55e97ed86567aafca2e5f3c19096e2a4cb50f - Sep 20th 2016) of commercialhaskell.com from github: {{{ https://github.com/commercialhaskell/commercialhaskell.com.git }}} follow instructions from that repo exactly for os x (stacksetup installed ghc-7.10.2, but i have seen similar issue with 8): {{{ $ brew install icu4c Add the following to your ~/.stack/stack.yaml: extra-include-dirs: - /usr/local/opt/icu4c/include extra-lib-dirs: - /usr/local/opt/icu4c/lib Now: $ stack build }}} Hit one minor issue in build process with icu4c, resolving with following stack build: {{{ stack build --extra-lib-dirs=/usr/local/opt/icu4c/lib --extra-include- dirs=/usr/local/opt/icu4c/include }}} reach build of yesod-auth, with a failure: {{{ yesod-auth-1.4.6: configure yesod-auth-1.4.6: build texmath-0.8.2.2: copy/register Progress: 35/38 -- While building package yesod-auth-1.4.6 using: /Users/stephen/.stack/setup-exe-cache/x86_64-osx/setup-Simple- Cabal-1.22.4.0-ghc-7.10.2 --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.4.0 build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /Users/stephen/Documents/github/commercialhaskell.com/.stack-work/logs /yesod-auth-1.4.6.log Configuring yesod-auth-1.4.6... Building yesod-auth-1.4.6... Preprocessing library yesod-auth-1.4.6... [ 1 of 11] Compiling Yesod.PasswordStore ( Yesod/PasswordStore.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/Yesod/PasswordStore.o ) /private/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/stack49268 /yesod-auth-1.4.6/Yesod/PasswordStore.hs:166:31: Warning: Defaulting the following constraint(s) to type ‘Integer’ (Integral b0) arising from a use of ‘^’ at Yesod/PasswordStore.hs:166:31 (Num b0) arising from the literal ‘32’ at Yesod/PasswordStore.hs:166:32-33 In the first argument of ‘(-)’, namely ‘2 ^ 32’ In the first argument of ‘(*)’, namely ‘(2 ^ 32 - 1)’ In the second argument of ‘(>)’, namely ‘(2 ^ 32 - 1) * hLen’ /private/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/stack49268 /yesod-auth-1.4.6/Yesod/PasswordStore.hs:419:1: Warning: Defined but not used: ‘toStrict’ /private/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/stack49268 /yesod-auth-1.4.6/Yesod/PasswordStore.hs:422:1: Warning: Defined but not used: ‘fromStrict’ [ 2 of 11] Compiling Yesod.Auth.Message ( Yesod/Auth/Message.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/Yesod/Auth/Message.o ) /private/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/stack49268 /yesod-auth-1.4.6/Yesod/Auth/Message.hs:22:1: Warning: The import of ‘Data.Monoid’ is redundant except perhaps to import instances from ‘Data.Monoid’ To import instances alone, use: import Data.Monoid() [ 3 of 11] Compiling Yesod.Auth.Routes ( Yesod/Auth/Routes.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.4.0/build/Yesod/Auth/Routes.o ) [ 4 of 11] Compiling Yesod.Auth ( Yesod/Auth.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.4.0/build/Yesod/Auth.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/ghc64990_0/libghc_21.dylib, 5): no suitable image found. Did find: /var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/ghc64990_0/libghc_21.dylib: malformed mach-o: load commands size (34176) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} So reporting.... I've seen the same error attempting to brew install haskell-stack on sierra betas 3 and 4, but on those occasions, an issue with libghc_44.dylib causing the problem. {{{ [ 4 of 87] Compiling System.Process.Read ( src/System/Process/Read.hs, dist/dist-sandbox-558713ad/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/ghc67839_0/libghc_44.dylib, 5): no suitable image found. Did find: /var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/ghc67839_0/libghc_44.dylib: malformed mach-o: load commands size (40560) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} stack version: {{{ Version 1.1.2, Git revision cebe10e845fed4420b6224d97dcabf20477bbd4b (3646 commits) x86_64 hpack-0.14.0 }}} stack exec env returns: {{{ stack exec env Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.tEAdTiAWFI/Render GHC_PACKAGE_PATH=/Users/stephen/Documents/github/commercialhaskell.com /.stack- work/install/x86_64-osx/lts-3.0/7.10.2/pkgdb:/Users/stephen/.stack/snapshots/x86_64-osx/lts-3.0/7.10.2/pkgdb:/Users/stephen/.stack/programs/x86_64-osx/ghc-7.10.2/lib/ghc-7.10.2/package.conf.d HASKELL_DIST_DIR=.stack-work/dist/x86_64-osx/Cabal-1.22.4.0 HASKELL_PACKAGE_SANDBOX=/Users/stephen/.stack/snapshots/x86_64-osx/lts-3.0/7.10.2/pkgdb HASKELL_PACKAGE_SANDBOXES=/Users/stephen/Documents/github/commercialhaskell… /.stack- work/install/x86_64-osx/lts-3.0/7.10.2/pkgdb:/Users/stephen/.stack/snapshots/x86_64-osx/lts-3.0/7.10.2/pkgdb: HOME=/Users/stephen LANG=en_IE.UTF-8 LOGNAME=stephen NAME=Stephen Barrett OLDPWD=/Users/stephen/Documents/github PATH=/Users/stephen/Documents/github/commercialhaskell.com/.stack- work/install/x86_64-osx/lts-3.0/7.10.2/bin:/Users/stephen/.stack/snapshots/x86_64-osx/lts-3.0/7.10.2/bin:/Users/stephen/.stack/programs/x86_64-osx/ghc-7.10.2/bin:/Users/stephen/Library/Haskell/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin PWD=/Users/stephen/Documents/github/commercialhaskell.com SECURITYSESSIONID=186a6 SHELL=/bin/bash SHLVL=1 SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.RTM6V8Lo2y/Listeners STACK_EXE=/Library/Haskell/ghc-8.0.1-x86_64/bin/stack TERM=xterm-256color TERM_PROGRAM=Apple_Terminal TERM_PROGRAM_VERSION=377 TERM_SESSION_ID=020844C9-1E8A-410E-8892-43DC0C5A8C0B TMPDIR=/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/ USER=stephen XPC_FLAGS=0x0 XPC_SERVICE_NAME=0 _=/usr/local/bin/stack __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x6C }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12479> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 59

[GHC] #11469: GHCi should get LANGUAGE extensions/defaulting from the module whose full top-level scope is visible
by GHC 19 Oct '17

19 Oct '17

#11469: GHCi should get LANGUAGE extensions/defaulting from the module whose full top-level scope is visible -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 7.11 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: -------------------------------------+------------------------------------- While helping a Haskell beginner today, we came across this behavior and I wondered why there wasn't already a ticket for this problem in the tracker. In fact, this is technically a duplicate of #3217, but that ticket is long (and it was difficult to find!) so I just want to file a new ticket to summarize what needs to be done. The essential problem is that a user is editing a file that looks like this: {{{ {-# LANGUAGE OverloadedStrings #-} module A where ... some code ... }}} and they load this into ghci with `ghci A.hs`. They then might reasonably type a string into the GHCi prompt and expect it to be overloaded... but it will not be! They had to have invoked GHCi with `ghci -XOverloadedStrings A.hs`. This behavior is unexpected and not very nice. The proposal is this: (from https://ghc.haskell.org/trac/ghc/ticket/3217#comment:15) GHCi should be changed so that at most one module is "fully open", currently denoted *M in GHCi's prompt. If a module M is "fully open", expressions typed at the GHCi prompt are interpreted (roughly) as if they were written in M itself. Specifically: * All the top-level things in the module are in scope * The per-module flags in {-# OPTIONS #-} and {-# LANGUAGE #-} pragmas * M's default declaration holds Note that currently more than one module can be fully open, and their top level scopes are merged. We propose to make that at most one. When compiling an expression typed on the GHCi command line: * Start with the baseline DynFlags * Apply flags specified on the original command-line * (Perhaps: apply flags specified by :set in this GHCi session. We aren't sure whether or not to do this.) * Apply GHCi baseline command-prompt flags (e.g. special defaulting rules) * Apply flags specified by :seti in this GHCi session * If there is a fully-open module M, apply flags specified in M itself. That is, flags in M get the last word. Implementing this plan will require some representation changes. In particular, since we need to apply M's source-code flags in two difference places, we really need to remember the diffs with M, perhaps as a `(DynFlags -> DynFlags)` function or something. See also: https://ghc.haskell.org/trac/ghc/ticket/3217#comment:28 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11469> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11343: Unable to infer type when using DuplicateRecordFields
by GHC 18 Oct '17

18 Oct '17

#11343: Unable to infer type when using DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- It seems to me that GHC should be able to easily infer the types for the record updates in this simple example. Is there a reason that it is unable to infer the type currently? {{{ {-# LANGUAGE OverloadedLabels, DuplicateRecordFields #-} module C where main = do print aThing print bThing print (aThing { a = 5 } ) print (bThing { a = 5 } ) data B = B { a :: Int} deriving Show bThing = B 10 data A = A { a :: Int } deriving Show aThing = A 10 {- [1 of 1] Compiling C ( C.hs, C.o ) C.hs:7:10: error: • Record update is ambiguous, and requires a type signature • In the first argument of ‘print’, namely ‘(aThing {a = 5})’ In a stmt of a 'do' block: print (aThing {a = 5}) In the expression: do { print aThing; print bThing; print (aThing {a = 5}); print (bThing {a = 5}) } -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11343> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10