There's a very similar issue if you try to do
import C hiding (foo)
This comes up if you have a module A exporting some duplicated record fields called f
, and a module B exporting some other variable called f
. You currently can't import A hiding f
, you have to import it qualified.
Michael Peyton Jones (bce59124) at 28 Mar 10:11
Fix trailing whitespace
Done
Michael Peyton Jones (4984cb03) at 27 Mar 17:33
Don't export userEventTracingEnabled
I'm thinking about the fantasy future I describe in #24021 (comment 539032), where if my package builds with a particular version of TH, I might get both forwards compatibility and backwards compatibility over some range of GHCs, which would make the upgrade path smooth for everyone. That would obviously require lots of effort, but I think it would be effort that looks a bit like this PR.
This is interesting also as some proof that the idea that in principle we could support older template-haskell
s with newer GHCs using a bit of CPP.
Good point. Given how small it is, I think it barely passes the Fairbarn threshold and as such is probably in fact not worth exporting. I'll remove it.
Yes, INLINABLE
doesn't work, sadly.
I agree that the current behaviour is reasonable, but it does make inline
rather useless.
cc @bgamari
Another updated version of !5316.
I made userEventTracingEnabled
impure, and exported it.
I've verified that we get the code that we want, as before we end up with some redundant reads that get optimized away in Cmm. Unfortunately due to #24589 a mere inline
+ INLINABLE
on getTraceFlags
is insufficient and I had to mark it as INLINE
.
Michael Peyton Jones (01eed2b7) at 25 Mar 18:03
base: speed up traceEventIO and friends when eventlogging is turned...
Michael Peyton Jones (97e0595a) at 25 Mar 18:02
base: speed up traceEventIO and friends when eventlogging is turned...
Michael Peyton Jones (5f9f36b8) at 25 Mar 18:01
Make userEventTracing impure, some renaming and documentation
Using the inline
magic function on a reference to a function that has been worker-wrapper-transformed may result in only the worker being inlined, which is unlikely to be what the user intended.
Observed when updating !5316 : getTraceFlags
needs to be inlined to get the best code, but I am observing that the worker is still present.
The worker should be inlined.
Optional:
Michael Peyton Jones (ec3de76b) at 25 Mar 17:06
Make userEventTracing impure, some renaming and documentation
... and 9330 more commits
Do we think that userTracingEnabled :: IO Bool
is a desirable part of the API? It's needed in this version of the PR because of the unsafePerformIO
, but if we get rid of that then I'm not sure we need it, unless we expect other users to use it?
Another way of looking at this is
ghc
cannot be compatible with multiple versions oftemplate-haskell(-internal)
because it can only be linked against one
Oh this is a good point, that I had not considered properly. Yes, you're right, we can't actually ever get "use one GHC with different versions of TH" so long as ghc
depends on template-haskell
. That renders my earlier suggestions rather pointless...
Of course this applies equally to a hypothetical haskell-syntax
.
This is a great point! Just to make this stuff clear for myself, in that scenario we'd imagine something like this:
I think even more concise:
graph TD
haskell-syntax
ghc --> haskell-syntax
template-haskell --> haskell-syntax
template-haskell --> ghc
U[user quotes] --> haskell-syntax
V[user splices] --> template-haskell
I'm unsure that this necessarily buys us much. Ultimately, we want to have compatibility between several versions of ghc
and template-haskell
: that means some compatibility code is going to have to go somewhere, and it's not clear to me that it's necessarily better in template-haskell
than ghc
? I guess it's easier to release new versions of template-haskell
.
The other consideration here is that if we consider the Big Picture for TTG, it has included the idea that we would merge the types used by GHC for Haskell source and the ones used by TH. In this world GHC would depend on haskell-syntax
or whatever to get its definitions for parsing Haskell and TH. So if we went in that direction it would strongly suggest the current dependency relationship rather than the one you suggest; or it would need the split that you propose where we would have template-haskell-syntax
(no GHC dependency, could merge with haskell-syntax
) and template-haskell
which depends on template-haskell-syntax
and ghc
.
If the only needed change is to remove the unsafe IO from userTracingEnabled
I can do that.
FYI HLS still uses ghc-trace-events
which is a shame. It would be nice if this could be finally incorporated!