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 <batterseapo...@hotmail.com> wrote: > On 26 August 2011 09:22, Simon Peyton-Jones <simo...@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. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
