May 2017 - ghc-tickets

[GHC] #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O)
by GHC 13 Jun '17

13 Jun '17

#12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | 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: -------------------------------------+------------------------------------- After upgrading to GHC 8.0.1 I've noticed that compilation time of one of my libraries got unacceptably long. Please find the attached test case. Here are some numbers from my machine: {{{ $ time ~/Prefixes/ghc-7.10.3/bin/ghc -O -c -Rghc-timing TypeList.hs Regression.hs <<ghc: 19103924976 bytes, 1441 GCs, 73048470/256579104 avg/max bytes residency (18 samples), 542M in use, 0.000 INIT (0.002 elapsed), 14.163 MUT (14.257 elapsed), 5.707 GC (5.830 elapsed) :ghc>> real 0m20.160s user 0m19.937s sys 0m0.197s $ time ~/Prefixes/ghc-8.0.1/bin/ghc -O -c -Rghc-timing TypeList.hs Regression.hs <<ghc: 147662211104 bytes, 9635 GCs, 190336418/433097448 avg/max bytes residency (38 samples), 1210M in use, 0.000 INIT (0.001 elapsed), 101.707 MUT (101.840 elapsed), 27.907 GC (28.259 elapsed) :ghc>> real 2m10.195s user 2m9.773s sys 0m0.400s }}} Both versions are the official Debian 8 x86_64 binaries from haskell.org. I also compiled the git master and unfortunately it is affected as well. It is worth mentioning that turning off optimization makes the problem disappear: {{{ $ time ~/Prefixes/ghc-8.0.1/bin/ghc -O0 -c -Rghc-timing TypeList.hs Regression.hs <<ghc: 3779057184 bytes, 225 GCs, 17923355/81566792 avg/max bytes residency (8 samples), 164M in use, 0.000 INIT (0.001 elapsed), 2.847 MUT (2.941 elapsed), 0.553 GC (0.572 elapsed) :ghc>> real 0m3.593s user 0m3.507s sys 0m0.073s }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12545> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #12582: HSOC Eventlog live profiling
by GHC 12 Jun '17

12 Jun '17

#12582: HSOC Eventlog live profiling -------------------------------------+------------------------------------- Reporter: NCrashed | Owner: NCrashed Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: eventlog | Operating System: Unknown/Multiple profile hsoc | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, it is ticket for results of my Haskell Summer of Code 2016 project [1]. The goal is provide feature for redirection of events to external profilers without an application termination. Proposed changes: * Changing eventlog file descriptor in runtime. {{{#!c /* * Set custom file stream for global event log sink. * * The function overwrites previous event log file pointer. Previouss * sink is closed only if closePrev flag is on. * * Writing to the sink is protected by global mutex. * * The function puts header to the new sink only when emitHeader flag * is on. User might not want the header if it is switching to * already existed eventlog handle that was switched away recently. */ void rts_setEventLogSink(FILE *sink, StgBool closePrev, StgBool emitHeader); /* * Get current file stream that is used for global event log sink. * * You shouldn't do anything with the pointer until * rts_setEventLogSink(otherFileOrNull, false) is called. After that * you can do anything with the file stream. */ FILE* rts_getEventLogSink(void); }}} * Special flag `-lm` for RTS to store eventlog in memory chunks. User space functions to retrieve the chunks from memory. {{{#!c /* * If RTS started with '-lm' flag then eventlog is stored in memory buffer. * * The function allows to pop chunks of the buffer. Return value of 0 means * that there is no any filled chunk of data. * * If the function returns nonzero value the parameter contains full chunk * of eventlog data with size of the returned value. Caller must free the * buffer, the buffer isn't referenced anywhere anymore. * * If nobody calls the function with '-lm' flag then the memory is kinda * to be exhausted. */ StgWord64 rts_getEventLogChunk(StgInt8** ptr); }}} * Feature for dynamic resize of eventlog buffers. {{{#!c /* * Reallocate inner buffers to match the new size. The size should be not * too small to contain at least one event. * * If RTS started with '-lm' the chunks of memory buffer is also resized. */ void rts_resizeEventLog(StgWord64 size); /* * Return current size of eventlog buffers. */ StgWord64 rts_getEventLogBuffersSize(void); }}} * Bindings to new features in `Debug.Trace` in `base` package. {{{#!hs -- | The 'setEventLogCFile' function changes current sink of the eventlog, if eventlog -- profiling is available and enabled at runtime. -- -- The second parameter defines whether old sink should be finalized and closed or not. -- Preserving it could be helpful for temporal redirection of eventlog data into not -- standard sink and then restoring to the default file sink. -- -- The third parameter defines whether new header section should be emitted to the new -- sink. Emitting header to already started eventlog streams will corrupt the structure -- of eventlog format. -- -- The function is more low-level than 'setEventLogHandle' but doesn't recreate underlying -- file descriptor and is intended to use with 'getEventLogCFile' to save and restore -- current sink of the eventlog. -- -- @since 4.10.0.0 setEventLogCFile :: Ptr CFile -> Bool -> Bool -> IO () -- | The 'getEventLogCFile' function returns current sink of the eventlog, if eventlog -- profiling is available and enabled at runtime. -- -- The function is intented to be used with 'setEventLogCFile' to save and restore -- current sink of the eventlog. -- -- @since 4.10.0.0 getEventLogCFile :: IO (Ptr CFile) -- | Setting size of internal eventlog buffers. The size should be not -- too small to contain at least one event. -- -- If RTS started with '-lm' the chunks of memory buffer is also resized. -- -- The larger the buffers the lesser overhead from event logging, but -- larger delays between data dumps. -- -- See also: 'getEventLogChunk', 'getEventLogBufferSize' setEventLogBufferSize :: Word -> IO () -- | Getting size of internal eventlog buffers. -- -- See also: 'setEventLogBufferSize', 'getEventLogChunk' getEventLogBufferSize :: IO Word -- | Get next portion of the eventlog data. -- -- If RTS started with '-lm' flag then eventlog is stored in memory buffer. -- -- The function allows to pop chunks out of the buffer. Return value of Nothing -- means that there is no any filled chunk of data. -- -- If the function returns nonzero value the parameter contains full chunk -- of eventlog data with size of the returned value. Caller must free the -- buffer with 'free' from 'Foreign.Marshal.Alloc', the buffer isn't referenced -- anywhere anymore. -- -- If nobody calls the function with '-lm' flag on then the memory is kinda -- to be exhausted. -- -- If '-lm' flag is off, the function returns always 'Nothing'. -- -- See also: 'setEventLogBufferSize' getEventLogChunk :: IO (Maybe CStringLen) }}} References: 1. [http://ncrashed.github.io/blog/posts/2016-06-12-hsoc-acceptance.html HSOC project description] 2. [http://ncrashed.github.io/blog/posts/2016-06-22-hsoc-rts.html Design choices for implementation] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12582> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11501: Building nofib/fibon returns permission denied
by GHC 08 Jun '17

08 Jun '17

#11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib | Version: 7.10.3 benchmark suite | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Building nofib/fibon returns permission denied: {{{ == make boot - --no-print-directory; in /h/ywang30/nofib/fibon/Hackage/Bzlib ------------------------------------------------------------------------ // Codec/Compression/BZip/Stream.hsc make[3]: execvp: //: Permission denied make[3]: *** [Codec/Compression/BZip/Stream.hs] Error 127 }}} Steps to reproduce: Edit nofib/mk/boilerplate.mk:35 to NoFibSubDirs = fibon make clean && make boot in nofib/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11501> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #13750: GHC produces incorrect coercions in hairy code
by GHC 08 Jun '17

08 Jun '17

#13750: GHC produces incorrect coercions in hairy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Andres Löh has been working with an optimized version of generics-sop, and ran into segfaults. He was able to reduce the test case to the attached (still not tiny) one, and could reduce it no further. He discovered the following utterly bogus definition in `-ddump-simpl` (with -O): {{{ Main.gshowP_$dAll :: All MyShow GHC.Exts.Any [GblId, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}] Main.gshowP_$dAll = ghc-prim-0.5.0.0:GHC.Classes.$p1(%,%) @ (All MyShow GHC.Exts.Any) @ (All (All MyShow) GHC.Exts.Any) (ghc-prim-0.5.0.0:GHC.Classes.C:(%%) `cast` (Sub (Sym (Main.D:R:AllFk_c[][0] <[*]>_N <All MyShow>_N)) ; Sym (Main.N:All[0] <[*]>_N <All MyShow>_N <'[]>_N) ; Sub (Nth:1 (Sub (Sym (Main.D:R:AllFkc:[0] <[*]>_N <All MyShow>_N <'[Char]>_N <'[]>_N)) ; (AllF <[*]>_N <All MyShow>_N ((':) <[*]>_N (UnsafeCo nominal '[Char] GHC.Exts.Any) (UnsafeCo nominal '[] GHC.Exts.Any))_N)_R ; Sub (Main.D:R:AllFkc:[0] <[*]>_N <All MyShow>_N <GHC.Exts.Any>_N <GHC.Exts.Any>_N))) ; Main.N:All[0] <[*]>_N <All MyShow>_N (UnsafeCo nominal GHC.Exts.Any (GHC.Exts.Any : GHC.Exts.Any)) ; Sub (Main.D:R:AllFkc:[0] <[*]>_N <All MyShow>_N <GHC.Exts.Any>_N <GHC.Exts.Any>_N) :: (() :: Constraint :: Constraint) ~R# ((All MyShow GHC.Exts.Any, All (All MyShow) GHC.Exts.Any) :: Constraint))) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13750> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #13666: The fake gcc can't handle trailing backslashes
by GHC 08 Jun '17

08 Jun '17

#13666: The fake gcc can't handle trailing backslashes ----------------------------------------+--------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Driver | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The fake gcc will choke on trailing backslashes in arguments, like -Iinclude\ or -Llibs\. `realgcc` handles them fine. It seems to insert as spurious quote or terminating a quote too early. Error message: {{{ .\test-ghc.c:1:20: fatal error: test-inc"/header.h: Invalid argument compilation terminated. }}} Found here: [https://github.com/idris-lang/Idris-dev/issues/3801] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13666> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #13373: Handle long file paths on Windows
by GHC 07 Jun '17

07 Jun '17

#13373: Handle long file paths on Windows ----------------------------------------+--------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- In the past, Cabal and GHC have run into Windows' PATH_MAX path size limitation, which caps the length of file system paths at 260 characters. Examples: * https://github.com/haskell/cabal/issues/3972 * https://ghc.haskell.org/trac/ghc/ticket/10777 It would be really great if Haskell's base libraries handled long file system paths correctly. There are a few possibilities for achieving this: * Call GetShortPathName https://msdn.microsoft.com/en- us/library/windows/desktop/aa364989(v=vs.85).aspx before calling any Windows API function, if we notice the file path is too long. The bad: Windows has to store the alias, and this aliasing mechanism may be disabled (but maybe this never happens in practice). * Rewrite the core libraries to use the Unicode versions of functions, which support longer paths. We need to add the `\\?\` prefix in this case. However, this prefix is not supported by all functions, and it turns off automatic expansion in the path string (so `..` is not interpreted.) Care would need to be taken to not break existing code. * For Windows 10 only, opt into transparent long path support using a manifest. See the bottom of https://msdn.microsoft.com/en- us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath Downside: this only works for Windows 10 An alternative plan is to build and publish an alternative Windows IO library, which is a drop-in replacement for the IO functionality implemented in base but is long paths. We can use this to test paths and provide better functionality to old versions of GHC, before merging the changes back into base proper. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13373> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11317: Test prog003 fails with segfault on Windows (GHCi)
by GHC 07 Jun '17

07 Jun '17

#11317: Test prog003 fails with segfault on Windows (GHCi) --------------------------------------+------------------------------- Reporter: rdragon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: #11234 Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- On my `x86_64` Windows machine test `prog003` fails with a segfault: {{{ cd ./ghci/prog003 && ghciWayFlags=-static HC="/home/Rik/ghc/inplace/bin /ghc-stage2.exe" HC_OPTS="-dcore-lint -dcmm-lint -dno-debug-output -no- user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history " "/home/Rik/ghc/inplace/bin/ghc-stage2.exe" -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS <prog003.script > prog003.run.stdout 2> prog003.run.stderr >> prog003.run.stdout 2>> prog003.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Run 1 a :: Int -> Int 168 Run 2 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 3 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 4 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 5 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 6 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 7 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 8 Segmentation fault/access violation in generated code Stderr: *** unexpected failure for prog003(ghci) }}} (I do not think it is an access violation error since when I remove [https://github.com/ghc/ghc/blob/c2fab84239299176a8e72aa26ae894019d677bd9/te… line 65] and everything below line 70, the same stdout is generated.) This looks related to ticket #11234. The GHC version used was [http://git.haskell.org/ghc.git/commit/df6cb57b32d94b7f6f7c9a86207adfeee9712… df6cb57b32d94b7f6f7c9a86207adfeee9712ed6], although I already noticed the problem with a version a few days older. If someone could point me to information about how to install GDB suitable for debugging GHC on my Windows machine I will try to post the stack trace. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11317> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8703: Use guard pages rather than heap checks
by GHC 07 Jun '17

07 Jun '17

#8703: Use guard pages rather than heap checks ------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- By mmap'ing memory using MAP_ANONYMOUS (or /dev/zero) as PROT_NONE (Windows has an equivalent functionality with VirtualAlloc), it's possible to create a page that will fault when read or written to. It may be possible to remove the heap checks in the runtime, speeding up allocations, and instead expand the heap when a fault is raised. This is likely cheaper for large pages full of many small allocations than the cost of the heap checking branch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8703> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13657: Documentation: Functional dependencies by other means
by GHC 07 Jun '17

07 Jun '17

#13657: Documentation: Functional dependencies by other means -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: 10431 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There's an idiom that's briefly mentioned under Equality constraints [section 10.14.1], but is more general and more powerful. The trouble: is where to document it? Because you get the power from a combination of extensions: * -XMultiParamTypeClasses [10.8.1.1] * Superclass constraints, which can also be MultiParam [10.8.1.2] * -XFunctionalDependencies [10.8.2] * and/or superclass Equality constraints with Type families, having the effect of FunDeps [10.14.1] * The overall effect can satisfy the FunDep Coverage conditions, which means you might not need -XUndecidableInstances [10.8.3.5] 10.14.1 says: > Equality constraints can also appear in class and instance contexts. The former enable a simple translation of programs using functional dependencies into programs using family synonyms instead. That's not wrong; but by talking about "class and instance contexts" in the same breath does fail to emphasise that: * whereas Instance constraints don't apply until after the instance has been selected\\(And it's a common newbie mistake to think they restrict the selection.) * superclass constraints apply during type improvement __before__ selecting instances\\as described here http://stackoverflow.com/questions/35252562/find-an-element-in-an- hlist/35260970#35260970 "superclass context is critical ..." [thanks @DFeuer] * This behaviour means that even if you don't explicitly put a FunDep `| ... -> ...` on a class: * If you put a superclass equality constraint on a class, that induces a FunDep as explained in 10.14.1; but just as much * If you put a superclass __class__ constraint on a class, and that superclass has a FunDep, that also induces a FunDep. * and so on for a superclass constraint of a superclass constraint of a superclass constraint .... I suggest the bulk of the write-up goes under a new sub-section for FunDeps: ---- == 10.8.2.3 Functional dependency-like behaviour through superclass constraints Constraints in the class context can achieve the effect of Functional dependencies even without the explicit vertical bar and dependency arrow syntax in the class declaration. Either: * Using an Equality constraint to a Type family [10.14.1]; or * A superclass constraint that does have an explicit Functional dependency. * Or a superclass constraint which is itself constrained in one of those ways. A class declaration of the form {{{ class C a b | a -> b }}} can equivalently be given as {{{ class (F a ~ b) => C a b where type F a }}} That is, we represent every functional dependency (FD) `a1 .. an -> b` by an FD type family `F a1 .. an` and a superclass context equality `F a1 .. an ~ b`, essentially giving a name to the functional dependency. [See 10.14.1; using `(~)` needs -XTypeFamilies or -XGADTs.] In class instances, we define the type instances of FD families in accordance with the class head. Or class `C` can equivalently be given as {{{ class (D a b) => C a b ... class D a b | a -> b -- or class (G a ~ b) => D a b where type G a }}} The class instances for `D` will closely follow those for `C`. So there is not much gain in expressivity. Consider also: {{{ class (D a c) => E a b c ... -- class D as above }}} for which the `D` instances will be more compact than `E`. Note that `D` might not declare any methods, but merely be used for type improvement. Method signatures for class `C` are not affected by either of these ways for achieving dependencies. ---- Reference this thread: https://mail.haskell.org/pipermail/glasgow-haskell- users/2017-April/026515.html, with some fancier examples of pseudo- FunDeps. See also #10431. Is this power made clear in the theoretical literature? It's kinda implicit in the TypeFamilies2008 paper; but note that was written concurrently with Type Families development; and published before the work was completed. Specifically, supporting Type Families and `(~)` in superclass constraints was delivered a long time after the rest of the work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13657> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12778: Expose variables bound in quotations to reify
by GHC 06 Jun '17

06 Jun '17

#12778: Expose variables bound in quotations to reify -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | 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: -------------------------------------+------------------------------------- Consider the following program: {{{ {-# LANGUAGE TemplateHaskell #-} module A where import Language.Haskell.TH as TH import Language.Haskell.TH.Syntax as TH foo :: IO () foo = $([| let x = True in $(do addModFinalizer $ do Just name <- TH.lookupValueName "x" TH.reify name >>= runIO . print [| return () |] ) |]) }}} When compiled, {{{TH.lookupValueName}}} fails to find {{{x}}}. {{{ $ inplace/bin/ghc-stage2 A.hs -fforce-recomp [1 of 1] Compiling A ( A.hs, A.o ) A.hs:7:9: error: • Pattern match failure in do expression at A.hs:9:23-31 • In the expression: (let x_a3Jy = True in return ()) In an equation for ‘foo’: foo = (let x_a3Jy = True in return ()) }}} It would make producing bindings in {{{inline-java}}} better if the type of {{{x}}} could be found in the finalizer. According to comments in ghc, {{{[| \x -> $(f [| x |]) |]}}} desugars to {{{ gensym (unpackString "x"#) `bindQ` \ x1::String -> lam (pvar x1) (f (var x1)) }}} which erases any hint that a splice point existed at all. This information is necessary to know which variables were in scope. How about we add a some new methods to the `Q` monad for the sake of marking inner splices: {{{ class Q m where ... qSpliceE :: m Exp -> m Exp qSpliceP :: m Pat -> m Pat qSpliceT :: m Type -> m Type ... }}} Now {{{[| \x -> $(f [| x |]) |]}}} would desugar to {{{ gensym (unpackString "x"#) `bindQ` \ x1::String -> lam (pvar x1) (qSpliceE (f (var x1))) }}} When the renamer executes these primitives, it would be aware of the inner splices and could treat them similarly to top-level splices. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12778> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13