... | ... | @@ -18,7 +18,7 @@ We want a `Data` instance for this type. |
|
|
I propose
|
|
|
|
|
|
```
|
|
|
derivinginstance(Data(XOverLit(GhcPass p)))=>Data(OverLit(GhcPass p))where…
|
|
|
derivinginstance(Typeable p,Data(XOverLit(GhcPass p)))=>Data(HsOverLit(GhcPass p))
|
|
|
```
|
|
|
|
|
|
|
... | ... | @@ -34,7 +34,7 @@ This is what is currently implemented in GHC master. It works, but every time th |
|
|
Alan would like to see
|
|
|
|
|
|
```
|
|
|
derivinginstanceData(OverLit(GhcPass p))
|
|
|
derivinginstanceData(HsOverLit(GhcPass p))
|
|
|
```
|
|
|
|
|
|
|
... | ... | @@ -47,7 +47,7 @@ This "does not compile". |
|
|
Alan has discovered that the three instances:
|
|
|
|
|
|
```
|
|
|
derivinginstanceData(OverLit(GhcPass'Parsed))derivinginstanceData(OverLit(GhcPass'Renamed))derivinginstanceData(OverLit(GhcPass'Typechecked))
|
|
|
derivinginstanceData(HsOverLit(GhcPass'Parsed))derivinginstanceData(HsOverLit(GhcPass'Renamed))derivinginstanceData(HsOverLit(GhcPass'Typechecked))
|
|
|
```
|
|
|
|
|
|
**will** compile, but only with GHC 8.2.1, not with 8.0.2, due to a flaw in the standalone deriving process.
|
... | ... | @@ -59,7 +59,23 @@ make three. |
|
|
|
|
|
\[ The spurious constraint problem was resolved by including `deriving instance Typeable c => Data (GhcPass c)`, as recommended by \@RyanGlScott \]
|
|
|
|
|
|
### PLAN C
|
|
|
### PLAN E
|
|
|
|
|
|
|
|
|
Proceed as per Plan A, but move all the standalone deriving code to a new file, which will produce orphan instances.
|
|
|
|
|
|
|
|
|
Inside this, use CPP to detect a modern enough compiler (GHC 8.2.1) to generate via Plan B, otherwise fall back to Plan A.
|
|
|
|
|
|
|
|
|
Eventually improve the standalone deriving sufficiently that it is able to generate a single traversal, instead of the three.
|
|
|
|
|
|
|
|
|
So for day-to-day work ghc devs can use GHC 8.2.1, and we confirm is still works with GHC 8.0.2 less frequently.
|
|
|
|
|
|
## Outdated/Infeasible Plans
|
|
|
|
|
|
### PLAN C (Infeasible)
|
|
|
|
|
|
|
|
|
It is still painful generating three virtually identical chunks of traversal code.
|
... | ... | @@ -83,7 +99,7 @@ instanceData(XOverLIt(GhcPass p))where |
|
|
That is: a no-op `Data` instances. Traversals would not traverse extension fields.
|
|
|
That might not be so bad, for now!
|
|
|
|
|
|
### PLAN D
|
|
|
### PLAN D (Infeasible)
|
|
|
|
|
|
|
|
|
If there were cases when we really did want to look at those extension fields,
|
... | ... | @@ -124,17 +140,3 @@ Note: |
|
|
- We are solving a compilation time problem for GHC stage1/stage2. The produced compiler has the same performance regardless of which derivation mechanism.
|
|
|
|
|
|
- Ideally we would like to end up with `data` instances for an arbitrary `OverLit p`, which is an outcome for Plan A. i.e. Plan A will play nice with external index types,for GHC API users. |
|
|
|
|
|
### PLAN E
|
|
|
|
|
|
|
|
|
Proceed as per Plan A, but move all the standalone deriving code to a new file, which will produce orphan instances.
|
|
|
|
|
|
|
|
|
Inside this, use CPP to detect a modern enough compiler (GHC 8.2.1) to generate via Plan B, otherwise fall back to Plan A.
|
|
|
|
|
|
|
|
|
Eventually improve the standalone deriving sufficiently that it is able to generate a single traversal, instead of the three.
|
|
|
|
|
|
|
|
|
So for day-to-day work ghc devs can use GHC 8.2.1, and we confirm is still works with GHC 8.0.2 less frequently. |