On 27 Jan 2010, at 18:17, Neil Mitchell wrote: > Hi >>> | These have always distressed me. Would it be feasible to refactor so >>> | that this isn't necessary, e.g. >>> | >>> | typecheck :: HsSyn Name () -> HsSyn Name PostTcInfo > >> The problem is that these annotations tend to be constructor-specific. You >> might get it to work with GADTs, but I'm not convinced >> that would be easier to use. > > You don't have to track this information in the type system. You could > rewrite: > > type PostTcType = Maybe Type > > Now you're representing the data that isn't there by a Nothing, rather > than a _|_. You could even newtype it and have fromPostTcType be > equivalent to fromJust with a helpful error about the ordering. It > will be slower than what's currently there, but also more accurate > statement of intent.
Yes, I don't know why it is implemented this way. Probably to avoid an indirection and the memory overhead. Could be worth measuring. > >> This causes problems when defining generic traversals over this syntax tree >> (e.g., using SYB). There is no easy type-based >> way of skipping over such values. > > Partly a warning, partly a plug - you might want to try Uniplate > instead of SYB, it's likely to be at least 3 times faster even if you > just layer it on top of the SYB/Data instances. I also feel that if > you start to "tweak" the data instances, you'll quickly run in to > problems - but maybe not. I know Uniplate. But there are two issues: 1. SYB will start using the table trick soon from what I hear, so I hope it won't be too slow. 2. How do I customise traversals based on context information? In SYB I use extQ, how would I do the same in Uniplate? E.g., if I wanted to gather all Id's but not those occurring inside SyntaxExpr (which are filled out by the renamer in order to describe which `>>=` to use and other things.) In any case, one would probably want both. If Uniplate/Biplate is enough, it's probably easier to use, but for more flexibility we want the option to use SYB. / Thomas _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
