Re: Panic when using syb with GHC API

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 wrote:

On 26 August 2011 09:22, Simon Peyton-Jones 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.