Closed RyanGlScott closed 3 years ago
Given how old 8.0 is now, I think it would be very reasonable to tighten the bounds and say that 8.0+ is required to build. Do you know of any uses that would break if a 7.x GHC wasn't supported anymore?
Do you know of any uses that would break if a 7.x GHC wasn't supported anymore?
Not that I'm aware of. I couldn't find an example of a project using llvm-pretty
that was relying on a pre-8.0 version of GHC, at least.
Thanks for looking, let's go ahead with tightening the bounds 👍
Sounds good to me.
As far as an answer to question (1) from https://github.com/elliottt/llvm-pretty/issues/81#issue-977022908 goes, I experimented to see what would happen if I gave everything in Text.LLVM.AST
a Lift
instance. Unfortunately, that doesn't quite work out of the box. That's because a handful of data types (e.g., Define
) have fields with Map
types, and Map
doesn't have a Lift
instance. There does exist a "canonical" orphan Lift
instance for Map
in the th-lift-instances
package, but using that in llvm-pretty
would require incurring an extra dependency.
In light of this, I think there are three possible options:
Lift
instance for everything by adding a dependency of th-lift-instances
.Lift
instance for all data types except those with Map
fields.Lift
instances for Symbol
, PrimType
, and Ident
, which are the three instances that are directly needed in GaloisInc/crucible#672.Why don't we see how far option 3 gets you, and we can revisit adding additional dependencies and instances if it turns out you need more?
Sounds good to me. See #82.
In GaloisInc/crucible#672, I found myself wanting
Lift
instances for theSymbol
,PrimType
, andIdent
data types fromText.LLVM.AST
to decrease the code size of TH splices involving these types. I'd like to add such instances to thellvm-pretty
library, and the most straightforward way to do this would be to attachderiving Lift
clauses to each of these data types. This proof-of-concept commit shows how it could be done.I have two questions I'd want to answer before I would feel comfortable submitting a patch for this:
Lift
instances for the three data types above, we could just as well defineLift
instances for all other types inText.LLVM.AST
. Would you have any objections to this idea?One complication is that the
DeriveLift
extension was introduced in GHC 8.0, butllvm-pretty.cabal
's version bounds onbase
seems to indicate that it supports pre-8.0 versions of GHC. In light of this, we could:i. Tighten up the version bounds to only allow 8.0 or later ii. Use CPP so that
deriving Lift
is only used when building with 8.0 or later iii. Define theLift
instances by hand to support all versions of GHCI'm not fond of option (iii), as defining
Lift
instances by hand is tedious. I don't have a strong opinion between options (i) and (ii). For what it's worth, the current version ofllvm-pretty
doesn't seem to actually support pre-8.0 in practice, since if you try to compile it with GHC 7.10.3, it will error out:So perhaps option (i) is needed anyway. Which option would you prefer?