November 2017 - ghc-tickets

[GHC] #13745: Investigate compile-time regressions in regex-tdfa-1.2.2
by GHC 01 Jun '18

01 Jun '18

#13745: Investigate compile-time regressions in regex-tdfa-1.2.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- hvr [[https://mail.haskell.org/pipermail/ghc- devs/2017-May/014208.html|points out]] that GHC 8.2 takes significantly longer to compile `regex-tdfa-1.2.2` than 8.0.2. Interestingly, it seems that compiler allocations fell dramatically while compilation time rose. {{{ GHC 8.0.2: <<ghc: 89544610040 bytes, 2301 GCs, 189183965/391103872 avg/max bytes residency (29 samples), 1075M in use, 0.001 INIT (0.001 elapsed), 55.747 MUT (61.520 elapsed), 23.276 GC (23.278 elapsed) :ghc>> GHC 8.2.1: <<ghc: 115210990008 bytes, 6383 GCs, 116487828/234031864 avg/max bytes residency (77 samples), 670M in use, 0.001 INIT (0.000 elapsed), 64.154 MUT (68.262 elapsed), 37.114 GC (37.077 elapsed) :ghc>> }}} == Reproducing == {{{ $ cabal unpack regex-tdfa-1.2.2 $ cd regex-tdfa-1.2.2 $ cabal install --only-dependencies $ cabal configure $ cabal build $ time ghc -idist/build/autogen -O2 Text/Regex/TDFA.hs \ -XMagicHash -XFlexibleInstances -XMultiParamTypeClasses \ -XRecursiveDo -XBangPatterns -XRankNTypes -XUnboxedTuples \ -XFlexibleContexts -XUnliftedFFITypes }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13745> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #9724: reexport IsList class from a trustworthy module
by GHC 31 May '18

31 May '18

#9724: reexport IsList class from a trustworthy module -------------------------------------+------------------------------------- Reporter: int-e | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- ==== Motivation GHC's Safe Haskell extension relies to a large extent on inferring safety of modules automatically. As a concrete example, [[http://hackage.haskell.org/package/data-default|data-default]] used to be inferred safe. This is no longer the case, because [[http://hackage.haskell.org/package/dlist-0.7.1|dlist-0.7.1]] added an {{{IsList}}} instance for difference lists. The only way to do that currently is to import the relevant parts of {{{GHC.Exts}}}, and that module is not safe. Of course the resulting non-safety of the {{{Data.DList}}} module can be fixed by adding a {{{TrustWorthy}}} pragma to the module and trusting the {{{dlist}}} package. But that is unsatisfactory, because there is nothing unsafe about providing an instance for the {{{IsList}}} class. This issue is bound to pop up in other packages as well. ==== Proposed Solution (this is one of many possibilities) Add a {{{GHC.Exts.Safe}}} module that is marked {{{TrustWorthy}}} and reexports the {{{IsList}}} class, and possibly other things from {{{GHC.Exts}}} that are safe to use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects
by GHC 31 May '18

31 May '18

#14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Keywords: | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm opening a fresh ticket as @bgamari suggested in #12479. There are few more related closed tickets as well: #12198 and #12588. The issue occurs on projects with a lot of dependencies. There are reports of that happening across various projects: [https://github.com/NixOS/nixpkgs/issues/22810] [https://github.com/commercialhaskell/stack/issues/2577] I'm still able to reproduce it with 8.2.1 and git HEAD with a work project: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/f8/2_rc4tgd1gj9vbgv7q9gbk4c0000gn/T/ghc94377_0/libghc_325.dylib, 5): no suitable image found. Did find: /var/folders/f8/2_rc4tgd1gj9vbgv7q9gbk4c0000gn/T/ghc94377_0/libghc_325.dylib: malformed mach-o: load commands size (34592) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I can't share the sources, but this is a command(generated by stack) that results in this error: `/Users/dr/.stack/setup-exe-cache/x86_64-osx/Cabal- simple_mPHDZzAJ_2.0.0.2_ghc-8.2.1 --builddir=.stack- work/dist/x86_64-osx/Cabal-2.0.0.2 build lib:projectname exe:projectname --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"` We're having a chat about this issue with @bgamari and I'll post some of his input: {{{ bgamari: dredozubov, unfortunately this is pretty much a limitation of OS X's linker bgamari: there's no great solution other than petitioning Apple to lift their arbitrary size limit bgamari: I've been asking people to open tickets with Apple bgamari: As they are really the only ones that can really fix this issue dredozubov: bgamari, do you know if someone did this already? bgamari: dredozubov, No one has said they have dredozubov: the other issue with it, I don't how to do a repro case dredozubov: I can reproduce it on a project with a closed sources and that's it bgamari: essentially you just need to build a project with enough dependencies bgamari: the problem is that Apple's linker sets an artificial cap on the number of shared libraries that an object file can load }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14444> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #9479: Report required constraints when reporting the type of a hole
by GHC 30 May '18

30 May '18

#9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: dominiquedevriese | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: holes | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- For the following code {{{ module Test where test :: String test = show _h }}} GHC currently reports: {{{ Found hole ‘_h’ with type: a0 Where: ‘a0’ is an ambiguous type variable Relevant bindings include test :: String (bound at /tmp/Test.hs:4:1) In the first argument of ‘show’, namely ‘_h’ In the expression: show _h In an equation for ‘test’: test = show _h }}} It correctly does not report the lack of a `Show _a` instance as a separate type error. However, it would be useful if the report containing the type of the hole would also contain the constraints that apply to its type. Something like: {{{ Found hole ‘_h’ with type: a0 Where: ‘a0’ is an ambiguous type variable Applicable constraints: Show a0 Relevant bindings include test :: String (bound at /tmp/Test.hs:4:1) In the first argument of ‘show’, namely ‘_h’ In the expression: show _h In an equation for ‘test’: test = show _h }}} I am explicitly *not* suggesting to report a type like `Show a0 => a0` for the hole, because that might mistakenly suggest that we are looking for a value of type `forall a0. Show a0 => a0`, which we are not. A possible alternative is to use an imaginary exists type like `exists a0. Show a0 => a0` but that's probably just even more confusing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9479> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS
by GHC 30 May '18

30 May '18

#12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS -------------------------------------+------------------------------------- Reporter: heisenbug | 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 this bare-bones module {{{#!hs {-# OPTIONS -fplugin GHC.TypeLits.Normalise #-} module A where }}} compiling it will always say {{{ $ ghc --make A.hs [1 of 1] Compiling A ( A.hs, A.o ) [GHC.TypeLits.Normalise changed] }}} even when the module was compiled before. {{{ $ ghc A.hs -c -ddump-if-trace -ddump-hi-diffs }}} will give the reason: {{{ imported module ‘GHC.TypeLits.Normalise’ is from package ‘ghc-typelits- natnormalise-0.5’, which is not among previous dependencies }}} Which is the probable cause: when writing the `.hi` file, the used plugins' package dependencies should be also written out. AFAICS they are extracted fron the `DynFlags` but for this comparison in {{{ checkDependencies :: HscEnv -> ModSummary -> ModIface -> IfG RecompileRequired }}} but not found in the `ModSummary` that was originally written to disk. This is pretty nasty for `clash` compilations and the suspected bug is documented here: https://github.com/clash-lang/ghc-typelits- natnormalise/issues/2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12567> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13838: -Wdeferred-type-errors; ghc: panic!; VoidRep; ((() -> ()) :: *) ~# (IO Any :: *)
by GHC 30 May '18

30 May '18

#13838: -Wdeferred-type-errors; ghc: panic!; VoidRep; ((() -> ()) :: *) ~# (IO Any :: *) -------------------------------------+------------------------------------- Reporter: harry | Owner: (none) 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 or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- My Compiler told me to report this so here you go: {{{ [1 of 1] Compiling Main ( ghc_bug.hs, interpreted ) ghc_bug.hs:3:1: warning: [-Wdeferred-type-errors] * Couldn't match expected type `IO t0' with actual type `() -> ()' * Probable cause: `main' is applied to too few arguments In the expression: main When checking the type of the IO action `main' ghc_bug.hs:3:8: warning: [-Wdeferred-type-errors] * Couldn't match expected type `() -> () -> ()' with actual type `()' * The function `()' is applied to one argument, but its type `()' has none In the expression: () () In an equation for `main': main = () () ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): corePrepPgm [False] cobox_r1a0 = typeError @ 'VoidRep @ ((() -> ()) :: *) ~# (IO Any :: *) "ghc_bug.hs:3:1: error:\n\ \ * Couldn't match expected type `IO t0' with actual type `() -> ()'\n\ \ * Probable cause: `main' is applied to too few arguments\n\ \ In the expression: main\n\ \ When checking the type of the IO action `main'\n\ \(deferred type error)"# Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{#!hs main :: () -> () main = () () }}} which that in "ghc_bug.hs" "ghc ghc_bug.hs -fdefer-type-errors -dcore-lint -v" gives me the following: {{{ Glasgow Haskell Compiler, Version 8.0.1, stage 2 booted by GHC version 7.10.3 Using binary package database: /usr/lib/ghc-8.0.1/package.conf.d/package.cache Using binary package database: /home/harry/.ghc/x86_64-linux-8.0.1/package.conf.d/package.cache loading package database /usr/lib/ghc-8.0.1/package.conf.d loading package database /home/harry/.ghc/x86_64-linux-8.0.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.0.1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: loading package database /usr/lib/ghc-8.0.1/package.conf.d loading package database /home/harry/.ghc/x86_64-linux-8.0.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.0.1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *ghc_bug.hs !!! Chasing dependencies: finished in 0.42 milliseconds, allocated 0.211 megabytes Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = ****-**-** **:**:**.********** *** ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file ghc_bug.hs *** Checking old interface for Main: [1 of 1] Compiling Main ( ghc_bug.hs, ghc_bug.o ) *** Parser [Main]: !!! Parser [Main]: finished in 0.14 milliseconds, allocated 0.089 megabytes *** Renamer/typechecker [Main]: !!! Renamer/typechecker [Main]: finished in 28.70 milliseconds, allocated 14.769 megabytes *** Desugar [Main]: Result size of Desugar (after optimization) = {terms: 19, types: 52, coercions: 4} *** Core Linted result of Desugar (after optimization): *** Core Lint errors : in result of Desugar (after optimization) *** <no location info>: warning: [RHS of cobox_aOD :: ((() -> ()) :: *) ~# (IO Any :: *)] The type of this binder is primitive: cobox_aOD Binder's type: ((() -> ()) :: *) ~# (IO Any :: *) *** Offending Program *** main :: () -> () [LclIdX, Str=DmdType] main = case typeError @ 'VoidRep @ (() :: *) ~# ((() -> () -> ()) :: *) "ghc_bug.hs:2:8: error:\n\ \ * Couldn't match expected type `() -> () -> ()'\n\ \ with actual type `()'\n\ \ * The function `()' is applied to one argument,\n\ \ but its type `()' has none\n\ \ In the expression: () ()\n\ \ In an equation for `main': main = () ()\n\ \(deferred type error)"# of cobox_aOE { __DEFAULT -> (() `cast` (Sub cobox_aOE :: (() :: *) ~R# ((() -> () -> ()) :: *))) () } $trModule :: Module [LclIdX, Str=DmdType] $trModule = Module (TrNameS "main"#) (TrNameS "Main"#) cobox_aOD :: ((() -> ()) :: *) ~# (IO Any :: *) [LclId[CoVarId], Str=DmdType] cobox_aOD = typeError @ 'VoidRep @ ((() -> ()) :: *) ~# (IO Any :: *) "ghc_bug.hs:2:1: error:\n\ \ * Couldn't match expected type `IO t0' with actual type `() -> ()'\n\ \ * Probable cause: `main' is applied to too few arguments\n\ \ In the expression: main\n\ \ When checking the type of the IO action `main'\n\ \(deferred type error)"# main :: IO Any [LclIdX, Str=DmdType] main = runMainIO @ Any (main `cast` (Sub cobox_aOD :: ((() -> ()) :: *) ~R# (IO Any :: *))) *** End of Offense *** <no location info>: error: Compilation had errors *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: }}} and gcc version is: gcc version 7.1.1 20170516 (GCC) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13838> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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] #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