Add Inject instance for tuples

[bosu]

(a, b) is mapped to { _1 = a, _2 = b }

[Gabriel439]

What I'd suggest doing here is to first define an R2 type, like this:

data R2 a b = R2 { _1 :: a, _2 :: b }
    deriving (Generic, Inject, Interpret)

... and then defining the Inject instance for the tuple by taking advantage of the Contravariant instance for InputType:

instance (Inject a, Inject b) => Inject (a, b) where
    injectWith = fmap (contraMap adapt) injectWith
      where
        adapt (_1, _2) = R2 {..})

The advantage of this approach is that it's easy to scale out to larger tuple sizes

The other advantage is that you can also export the R{N} family of constructors so that users can also use those directly instead of tuples if they want the correspondence to the Dhall type to be more clear

[Gabriel439]

Also, while you're doing this, you can also define a matching Interpret instance for tuples, too

[bosu]

What I'd suggest doing here is to first define an R2 type, like this:

You are right, this looks much better. I'll update the pull request.

Also, while you're doing this, you can also define a matching Interpret instance for tuples, too

Will do.

[bosu]

Rebased and updated the pull request.

[Gabriel439]

It looks like the build failure is not your fault. Somehow the ansi-terminal-0.7 release has confused cabal's solver. I'm still digging into exactly why

[Gabriel439]

It looks like the build failure is not your fault. Somehow the ansi-terminal-0.7 release has confused cabal's solver. I'm still digging into exactly why

[Gabriel439]

If you add the DeriveAnyClass extension, then you can simplify this further as just:

data R2 a b = R2 { _1 :: a, _2 :: b }
    deriving (Generic, Inject, Interpret, Show)

[bosu]

Update pull request uses DeriveAnyClass

[Gabriel439]

I'll go ahead and merge this and then fix the build failure on master separately since this pull request is not the cause of the problem