Trees that Grow and constraints
Shayan Najd
sh.najd at gmail.com
Mon Nov 13 16:36:14 UTC 2017
Isn't the solution always
if generic programming makes things complicated, avoid it!
Here generic programming is where you define instances parametric on the
phase index.
Why not defining three instances of the type class, one per each phase?
Yes, we get code duplication (which in this case is still not much as we
use automatic deriving), but the compilation gets faster (which is the
motivation), like [2].
[2] http://lpaste.net/360019
/Shayan
On Mon, Nov 13, 2017 at 2:05 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com>
wrote:
> Just to clarify, this example is a simplification, in practice we would be
> applying different type for each type instance
>
> e.g.
>
> type instance XEOverLit (GhcPass 'Parsed ) = PlaceHolder
> type instance XEOverLit (GhcPass 'Renamed ) = PlaceHolder
> type instance XEOverLit (GhcPass 'Typechecked) = Type
>
> (modelling existing PostTc)
>
> Alan
>
> On 13 November 2017 at 11:23, Alan & Kim Zimmerman <alan.zimm at gmail.com>
> wrote:
>
>> At the moment the Trees that Grow implementation in GHC master makes use
>> of massive constraint types to provide Data instances for the hsSyn AST.
>>
>> I am trying to remove the need for this, and have hit a problem.
>>
>> The example I have reduced it to is here [1]
>>
>> The essence of the problem is
>>
>> -------------------
>> data Experiment p
>> = Experiment {
>> e_ext :: (XEOverLit p),
>> e_val :: Int }
>> | XExperiment (XXOverLit p)
>> deriving instance (Data (GhcPass p)) => Data (Experiment (GhcPass p))
>>
>> type family XEOverLit x
>> type family XXOverLit x
>>
>> -- The following line works
>> -- type instance XEOverLit (GhcPass _) = PlaceHolder
>>
>> -- The following 3 lines do noe
>> type instance XEOverLit (GhcPass 'Parsed ) = PlaceHolder
>> type instance XEOverLit (GhcPass 'Renamed ) = PlaceHolder
>> type instance XEOverLit (GhcPass 'Typechecked) = PlaceHolder
>>
>> type instance XXOverLit (GhcPass _) = PlaceHolder
>> -------------------
>>
>> Where specifying the type instance with a wild card keeps GHC happy (the
>> XXOverLit case), but specifying for each of the three constructors for pass
>> does not (the XEOverLit case)
>>
>> The exact error message is
>>
>> ------------------------------
>> Experiment.hs:34:1: error:
>> • Could not deduce (Data (XEOverLit (GhcPass p)))
>> arising from a use of ‘k’
>> from the context: Data (GhcPass p)
>> bound by the instance declaration at Experiment.hs:34:1-69
>> • In the first argument of ‘k’, namely ‘(z Experiment `k` a1)’
>> In the expression: ((z Experiment `k` a1) `k` a2)
>> In an equation for ‘gfoldl’:
>> gfoldl k z Experiment a1 a2 = ((z Experiment `k` a1) `k` a2)
>> When typechecking the code for ‘gfoldl’
>> in a derived instance for ‘Data (Experiment (GhcPass p))’:
>> To see the code I am typechecking, use -ddump-deriv
>> |
>> 34 | deriving instance (Data (GhcPass p)) => Data (Experiment (GhcPass p))
>> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> ^^^^^^^^^
>> ------------------------------
>>
>> Alan
>>
>> [1] http://lpaste.net/360017
>>
>>
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171113/5c831342/attachment-0001.html>
More information about the ghc-devs
mailing list