Hi,<br><br><div class="gmail_quote">On Fri, Aug 26, 2011 at 10:22, Simon Peyton-Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Feel free to propose better solutions.<br></blockquote><div><br>I see the problem, but it's indeed not clear how to improve the current situation.<br><br>Adding one more possible solution: SYB, as it is, will traverse the entire data structure, even if it is clear (from the types) that there will be nothing to transform inside a certain term.<br>
<br>A while ago, Claus Reinke developed a different form of traversals for SYB, which avoid entering subterms when it is clear that there is nothing to transform there. You can see the code in a branch of the current repo: <a href="https://github.com/dreixel/syb/blob/gps/src/Data/Generics/GPS.hs">https://github.com/dreixel/syb/blob/gps/src/Data/Generics/GPS.hs</a><br>
<br>Maybe using this could help, since then SYB would not traverse everything. In general, however, this is still not a complete solution, because you might have written a traversal which does intend to operate inside these undefined values: you just don't expect them to be undefined.<br>
<br>In any case, maybe Simon Hengel can try using this. If it seems like this avoids the problem, I'd be happy to release a new version of SYB containing these type-guided traversals. (Also, for traversing these kind of big structures, using Claus's traversals might improve performance considerably.)<br>
<br><br>Cheers,<br>Pedro<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
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:<br>
<br>
Parsed: HsExpr RdrNames<br>
Renamed: HsExpr Name<br>
Typechecked: HsExpr Id<br>
<br>
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<br>
<br>
Renamed: HsExpr Name ()<br>
Typechecked: HsExpr Id Type<br>
<br>
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.<br>
<br>
Another possibility would be for those PostTcTypes to be (Maybe Type), which would be less convenient when you know they are there.<br>
<br>
Simon<br>
<br>
| -----Original Message-----<br>
| From: <a href="mailto:glasgow-haskell-users-bounces@haskell.org">glasgow-haskell-users-bounces@haskell.org</a> [mailto:<a href="mailto:glasgow-haskell-users-">glasgow-haskell-users-</a><br>
| <a href="mailto:bounces@haskell.org">bounces@haskell.org</a>] On Behalf Of Ranjit Jhala<br>
| Sent: 25 August 2011 22:47<br>
| To: Thomas Schilling<br>
| Cc: <a href="mailto:glasgow-haskell-users@haskell.org">glasgow-haskell-users@haskell.org</a><br>
| Subject: Re: Panic when using syb with GHC API<br>
<div><div></div><div class="h5">|<br>
| Hi,<br>
|<br>
| I ran into a similar issue earlier -- you might also look at this<br>
|<br>
| <a href="http://mistuke.wordpress.com/category/vsx/" target="_blank">http://mistuke.wordpress.com/category/vsx/</a><br>
|<br>
| (also linked from <a href="http://haskell.org/haskellwiki/GHC/As_a_library#Links" target="_blank">http://haskell.org/haskellwiki/GHC/As_a_library#Links</a>)<br>
|<br>
| Hope to elaborate the text there one of these days...<br>
|<br>
| Ranjit.<br>
|<br>
|<br>
| On Aug 25, 2011, at 2:22 AM, Thomas Schilling wrote:<br>
|<br>
| > GHC's parse tree contains lots of placeholders. You are not supposed<br>
| > to look at them until a specific phase has been run. For example,<br>
| > anything of type "SyntaxExpr" is an error thunk until the renamer has<br>
| > been run. Unfortunately, SyntaxExpr is just a type synonym, so<br>
| > there's no way to distinguish them via SYB.<br>
| ><br>
| > The simplest workaround is to adapt the default traversal code for the<br>
| > nodes which may contain such error thunks. A better solution would be<br>
| > to change the GHC AST to wrap such possibly undefined nodes with<br>
| > newtypes, but that would only take effect once the next version of GHC<br>
| > is released.<br>
| ><br>
| > On 24 August 2011 23:11, Simon Hengel <<a href="mailto:simon.hengel@wiktory.org">simon.hengel@wiktory.org</a>> wrote:<br>
| >> Hello,<br>
| >> I'm trying to query a type-checked module with syb, this works for a<br>
| >> plain binding. But as soon as I add a type signature for that binding,<br>
| >> I get an "panic!"<br>
| >><br>
| >> I experienced similar problems with a renamed module.<br>
| >><br>
| >> Are those data structures meant to be used with syb? And if yes, what<br>
| >> did I miss?<br>
| >><br>
| >> Bellow is some code to reproduce my issue. Any help is very much<br>
| >> appreciated.<br>
| >><br>
| >> -- A.hs<br>
| >> module Main where<br>
| >><br>
| >> import GHC<br>
| >> import Outputable<br>
| >> import Data.Generics<br>
| >> import GHC.Paths (libdir)<br>
| >><br>
| >> import Bag<br>
| >><br>
| >> main :: IO ()<br>
| >> main = do<br>
| >> m <- parse<br>
| >> putStrLn $ showSDoc $ ppr $ m<br>
| >> putStrLn "\n---\n"<br>
| >> putStrLn $ showSDoc $ ppr $ selectAbsBinds m<br>
| >><br>
| >> parse = runGhc (Just libdir) $ do<br>
| >> _ <- getSessionDynFlags >>= setSessionDynFlags<br>
| >> target <- guessTarget "B.hs" Nothing<br>
| >> setTargets [target]<br>
| >> Succeeded <- load LoadAllTargets<br>
| >> modSum <- getModSummary $ mkModuleName "B"<br>
| >> m <- parseModule modSum >>= typecheckModule<br>
| >> return $ typecheckedSource m<br>
| >><br>
| >> selectAbsBinds :: GenericQ [HsBindLR Id Id]<br>
| >> selectAbsBinds = everything (++) ([] `mkQ` f)<br>
| >> where<br>
| >> f x@(AbsBinds _ _ _ _ _) = [x]<br>
| >> f _ = []<br>
| >><br>
| >><br>
| >> -- B.hs<br>
| >> module B where<br>
| >><br>
| >> foo :: Char<br>
| >> foo = 'f'<br>
| >><br>
| >> Cheers,<br>
| >> Simon<br>
| >><br>
| >> _______________________________________________<br>
| >> Glasgow-haskell-users mailing list<br>
| >> <a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>
| >> <a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>
| >><br>
| ><br>
| ><br>
| ><br>
| > --<br>
| > Push the envelope. Watch it bend.<br>
| ><br>
| > _______________________________________________<br>
| > Glasgow-haskell-users mailing list<br>
| > <a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>
| > <a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>
|<br>
|<br>
| _______________________________________________<br>
| Glasgow-haskell-users mailing list<br>
| <a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>
| <a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>
<br>
<br>
_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>
</div></div></blockquote></div><br>