> One way to think of it is this: we can now put SrcSpans where they make > sense, rather than everywhere.
I claim an SrcSpan makes sense everywhere, so this is not a useful distinction. Think about it as code provenance, an AST node always comes from somewhere: a user-written .hs file, a GHCi command, or compiler-generated code (via TH or deriving). We should never omit this information from a node. And when we are writing code that consumes an AST, it always makes sense to ask what the provenance of a node is, for example to use it in an error message. > this lets us add more than one; that's redundant but not harmful It goes against the philosophy of making illegal states irrepresentable. Now all code must be careful not to end up in an illegal state of nested SrcSpan, without any help from the typechecker. The code that pattern matches on an AST, at the same time, must be prepared to handle this case anyway (or else we risk to crash), which it currently does with stripSrcSpanPat in the implementation of dL. And having to remember to apply dL when matching on the AST is more trivia to learn and remember. Not even a warning if one forgets to do that, no appropriate place to explain this to new contributors (reading another Note just to start doing anything at all with the AST? unnecessary friction), and only a test failure at best in case of a mistake. My concrete proposal: let's just put SrcSpan in the extension fields of each node. In other words, take these lines type instance XVarPat (GhcPass _) = NoExt type instance XLazyPat (GhcPass _) = NoExt type instance XAsPat (GhcPass _) = NoExt type instance XParPat (GhcPass _) = NoExt type instance XBangPat (GhcPass _) = NoExt ... and replace them with type instance XVarPat (GhcPass _) = SrcSpan type instance XLazyPat (GhcPass _) = SrcSpan type instance XAsPat (GhcPass _) = SrcSpan type instance XParPat (GhcPass _) = SrcSpan type instance XBangPat (GhcPass _) = SrcSpan ... And don't bother with the HasSrcSpan class, don't define composeSrcSpan and decomposeSrcSpan. Very straightforward and beneficial for both producers and consumers of an AST. All the best, Vladislav _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs