Panic when using syb with GHC API

[Thomas Schilling]

Yep, I've been thinking about that.  It could work, but I don't know
how type functions interact with SYB.

It doesn't solve the issue of having traversals with different
semantics, though.  I.e., sometimes you want to look inside
SyntaxExpr, sometimes you don't.  ATM, you have to customise the
traversal for each data type that has a constructor which may contain
a SyntaxExpr.  It would be simpler to have a newtype for these, so
that you only have to change the behaviour for that single type.

On 26 August 2011 17:53, Max Bolingbroke <batterseapower at hotmail.com> wrote:
> On 26 August 2011 09:22, Simon Peyton-Jones <simonpj at microsoft.com> wrote:
>> The underlying issue is that before type checking GHC (obviously) doesn't know the types of things, while afterwards it does.  The whole HsSyn tree is parameterised over the types of identifiers:
>>
>>  Parsed:       HsExpr RdrNames
>>  Renamed:      HsExpr Name
>>  Typechecked:  HsExpr Id
>>
>> One alternative would be to parameterise the tree over the type of type-decorations, so instead of 'PostTcType' you'd have 'ty' (a variable) instead.  So we'd have
>>
>>  Renamed:     HsExpr Name ()
>>  Typechecked: HsExpr Id   Type
>>
>> To me this seems like a bit of a sledgehammer to crack a nut; and I think there are a couple of other similar things (like SyntaxExpr).  But it might be possible.
>
> Type functions?
>
> data HsExpr name = ... | HasTypeArgument (TypeInfo name)
>
> type family TypeInfo name :: *
> type instance TypeInfo RdrName = ()
> type instance TypeInfo Name = Type
>
> This basically lets you get away with just a single type index to
> HsExpr and friends.
>
> Max
>



-- 
Push the envelope. Watch it bend.