- ghc-devs - Haskell.org

Restrictions on polytypes with type families
by Richard Eisenberg 12 Nov '13

12 Nov '13

Hi all, GHC doesn't allow type families to be used with polytypes: 1) The right-hand side of a type family instance cannot have a "forall". 2) A type family cannot be applied to a type containing a "forall". 3) A pattern in a type family instance is (oddly) allowed to contain "forall", but this is silly because of (2). Do these restrictions have known reasons for their existence? Or, are there any that are restricted because someone needs to think hard before lifting it, and no one has yet done that thinking? I know, for example, that the unify function in types/Unify.lhs will have to be completed to work with foralls, but this doesn't seem hard. I've run into two separate cases where I've hit this restriction, so this isn't just idle thought. Thanks, Richard

8 15

Finding & assembling class dictionaries from GHC plugins?
by Conal Elliott 12 Nov '13

12 Nov '13

I'm working on a GHC plugin (for compiling Haskell to hardware), and I need to synthesize Typeable (and maybe other) class dictionaries for a wide range of types, including composite types (functions, pairs, lists, etc). Can it be done, and how? I think I'm mainly looking for mechanics of finding existing class instances (however they're defined) and assembling them (for parametrized/composite dictionaries), rather than mechanisms specific to Typeable. Thanks, -- Conal

3 12

Pattern match failure in StgCmmExpr.hs when adding new out-of-line primop
by Edsko de Vries 12 Nov '13

12 Nov '13

Hi guys, I'm trying to add a new primop; as a starting point I just copied the definition of "catch#" in primops.txt.pp and renamed "catch#" to "catchRethrow#", and added the corresponding declarations following https://ghc.haskell.org/trac/ghc/wiki/Commentary/PrimOps#AddinganewPrimOp ; however, when I do this, I get ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.7.20131108 for x86_64-apple-darwin): compiler/codeGen/StgCmmExpr.hs:508:15-48: Irrefutable pattern failed for pattern (CoreSyn.DEFAULT, deflt) I can't quite figure out why that is happening and how I should address it. Any suggestions? Thanks! -E

1 1

Re: Pattern match failure in StgCmmExpr.hs when adding new out-of-line primop
by Edsko de Vries 12 Nov '13

12 Nov '13

Hi Arash, On Tue, Nov 12, 2013 at 10:44 AM, Arash Rouhani <rarash(a)student.chalmers.se> wrote: > I'm really curious why you want a "catchRethrow". I'm tempted to add such > a primop myself since I'm working on problems with stack traces. I'm really > interested in what use-case you had in mind. > I'm working on dealing with problems with re-throwing asynchronous exceptions, especially in the context of using unsafePerformIO (see #8006 and the other tickets I reference there at the top). The catchRethrow I'm playing with is supposed to be used something like threadCode :: IO () threadCode = catch (print notReallyPure) outerHandler where outerHandler :: SomeException -> IO () outerHandler e = logMsg $ "Outer handler: " ++ show e notReallyPure :: Integer notReallyPure = unsafePerformIO $ catchRethrow (go 10) innerHandler where go :: Integer -> IO Integer go 0 = return 1234 go n = do logMsg (show n) threadDelay 100000 go (n - 1) innerHandler :: SomeException -> IO Integer -> IO Integer innerHandler e rethrow = do logMsg $ "Inner handler: " ++ show e rethrow logMsg :: String -> IO () logMsg str = do tid <- myThreadId putStrLn $ show tid ++ ": " ++ str Given this main: main :: IO () main = do a1 <- async threadCode a2 <- async threadCode threadDelay 500000 cancel a1 wait a2 return () It should be the case that when thread a1 gets interrupted, thread a2 can continue evaluating the notReallyPure thunk without getting either an exception and without redoing any work. In other words, the output of this main should look like ThreadId 2: 10 ThreadId 2: 9 ThreadId 2: 8 ThreadId 2: 7 ThreadId 2: 6 ThreadId 2: Inner handler: thread killed ThreadId 2: Outer handler: thread killed ThreadId 3: 5 ThreadId 3: 4 ThreadId 3: 3 ThreadId 3: 2 ThreadId 3: 1 1234 -E

1 0

Windows build
by Simon Peyton-Jones 12 Nov '13

12 Nov '13

Austin, or others, It would be SO GREAT if it was possible to validate on Windows again. Currently I'm using msys2, which builds GHC fine, but things fail badly in the testsuite. Traceback (most recent call last): File "../driver/runtests.py", line 144, in <module> raise Exception("Can't detect Windows terminal type") Exception: Can't detect Windows terminal type uname -s returns MINGW_NT-6.2 Changing the test from elif v.startswith("MINGW32"): to elif v.startswith("MINGW"): just produces a new error Traceback (most recent call last): File "../driver/runtests.py", line 155, in <module> mydll = ctypes.windll AttributeError: 'module' object has no attribute 'windll' ../mk/test.mk:242: recipe for target 'test' failed It's all very frustrating because I can't validate. Can anyone help? Simon

2 3

Things stopping pure Haskell code from having a cross-platform single semantics?
by Ryan Newton 12 Nov '13

12 Nov '13

Haskell isn't like Java byte code in having a single semantics for a program irrespective of where it is run. In particular, "Int" has a platform-defined width -- so the same (pure) code can yield different answers on different machines. numCapabilities was also a "leak" of platform information, which did not require IO. But, happily, now it does not appear in the [Trustworthy] module, Control.Concurrent. Ok, what else? What other holes are there that allow my pure functions to change their answer on different machines? I'm making a list of these in a paper and I want to make sure I give a full account. Thanks, -Ryan

2 1

Annotations
by Simon Peyton-Jones 08 Nov '13

08 Nov '13

I've just noticed that there is no GHC language extension for annotations http://www.haskell.org/ghc/docs/latest/html/users_guide/extending-ghc.html#… That feels like an oversight. Yes, they are in a pragma, but you may get an error message if you compile with a stage-1 compiler, for example. Plus, the language extensions should truthfully report what extra stuff you are using. I'm inclined to add a language extension "Annotations". * Without it {-# ANN ... #-} pragmas are ignored as comments * With it, they are treated as annotations Do you agree? I don't know whether this can (or even should) land in 7.8.1. Do you care either way? Guidance welcome Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

5 7

simd branch ready for review/merge
by Geoffrey Mainland 08 Nov '13

08 Nov '13

The SIMD branch, available as wip/simd, is ready for review/merge. It could use some review---Simon and Simon, I'd be especially grateful if you both had a quick look. Some major points: 1) I have added support for AVX 512, although this is necessarily untested. AVX and AVX2 are also both supported. 2) After the recent churn regarding patching LLVM's GHC calling convention, by default only 128-bit wide SIMD vectors are passed in registers, and then only on X86_64. There is a "hidden" flag, -fllvm-pass-vectors-in-regs, that causes GHC to generate LLVM code that assumes all vectors are passed in registers by LLVM. This can be used with a suitably patched version of LLVM, and if we get LLVM 3.4 patched, we can consider turning it on by default for LLVM 3.4+. This would mean that we couldn't mix LLVM <3.3-compiled object files with LLVM >3.4-compiled object files, but I don't see that as much of a problem. 3) utils/genprimcode has been hacked up to allow us to write vector operations once and have them instantiated at multiple vector types. I'm not thrilled with this solution, but after discussing with Simon PJ, what I've implemented seems to be the minimal reasonable solution to the problem of exploding primop boilerplate. The changes are documented in compiler/prelude/primops.txt.pp. 4) Error handling is sub-optimal. My patch checks to make sure that vector primops can be compiled efficiently based on the current set of dynamic flags. For example, if -mavx is not specified and the user tries to use a primop that adds together two 256-bit wide vectors of double-precision elements, the user will see an error message like: ghc-stage2: sorry! (unimplemented feature or known bug) (GHC version 7.7.20130916 for x86_64-unknown-linux): 256-bit wide floating point SIMD vector instructions require at least -mavx. This is because the only good place to check for this kind of error is during STG->Cmm translation (in compiler/codeGen/StgCmmPrim.hs), and we don't have much of an error handling infrastructure there in contrast to when we're working in the typechecking/renaming monad. If there is a better way/place to do this, please let me know. Thanks, Geoff

4 8

Possible bug related to stm and exceptions
by Andreas Voellmy 07 Nov '13

07 Nov '13

Hi all, I have a program that uses STM heavily and also performs lots of foreign calls. I've noticed that sometimes the program uses 100% CPU indefinitely and uses lots of memory - I see it go up to about 5GB before I kill it. I've grabbed some preliminary samples of stack traces and see lots stm related stuff (e.g. lots of stg_atomically_frame_info and stmCommitTransaction entries). I can pretty reliably get the behavior to happen now by closing a socket that my Haskell program is trying to recv from. When this causes an exception to be raised (something like "recv: resource vanished (Connection reset by peer)") , then this behavior gets triggered. I haven't pinned down the bug yet, but I'm suspecting it is STM related - somehow the exception causes some STM transaction to go wrong. Are there any known bugs that sound similar to this? BTW, this is with GHC 7.6.3 from a recent HP release on OS X. -Andi

4 6

windows agiain
by Simon Peyton-Jones 07 Nov '13

07 Nov '13

Austin I'm crashing in the testsuite as below. On Windows with the new msys. Any ideas? How do I set my "Windows terminal type"? Simon python2 ../../../driver/runtests.py -e ghc_compiler_always_flags="'-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts '" -e ghc_debugged=False -e ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e ghc_with_dynamic=1 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=1 -e ghc_with_interpreter=0 -e ghc_unregisterised=0 -e ghc_dynamic_by_default=False -e ghc_dynamic=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=True -e darwin=False -e in_tree_compiler=True -e clean_only=False --rootdir=. --config=../../../config/ghc -e 'config.confdir="../../../config"' -e 'config.compiler="C:/code/HEAD/inplace/bin/ghc-stage1.exe"' -e 'config.ghc_pkg="C:/code/HEAD/inplace/bin/ghc-pkg.exe"' -e 'config.hp2ps="C:/code/HEAD/inplace/bin/hp2ps.exe"' -e 'config.hpc="C:/code/HEAD/inplace/bin/hpc.exe"' -e 'config.gs="gs"' -e 'config.platform="i386-unknown-mingw32"' -e 'config.os="mingw32"' -e 'config.arch="i386"' -e 'config.wordsize="32"' -e 'default_testopts.cleanup=""' -e 'config.timeout=int() or config.timeout' -e 'config.timeout_prog="../../../timeout/install-inplace/bin/timeout.exe"' -e 'config.exeext=".exe"' -e 'config.top="C:/code/HEAD/testsuite"' \ --only=T8037 \ \ \ \ \ \ Traceback (most recent call last): File "../../../driver/runtests.py", line 144, in <module> raise Exception("Can't detect Windows terminal type") Exception: Can't detect Windows terminal type ../../../mk/test.mk:242: recipe for target 'test' failed make: *** [test] Error 1 should_compile $

1 0