Bernard James POPE (bjpop@cs.mu.OZ.AU)
Tue, 22 Aug 2000 18:27:14 +1000 (EST)
Hi Olaf, [ stuff about insertion of "| Prelude.True" Guards into the syntax tree after parsing] > I believe that these guards are inserted to simplify the definition of > the syntax tree: every equation has a guard. However, I find it > annoying, too, and at some time in the future I want to change the > definition of the syntax tree to use a Maybe type. I would prefer that nhc used the HsSyn.lhs module of the Happy Haskell parser (or at least something similar to this). I think, though I'm not 100% sure, that ghc uses this now. It would be nice if the compilers/ interpreters could agree on an internal syntax description (or at least an interface to the syntax description) - it would make porting some front end stuff between them easier. I think I remember reading somewhere (I forget where) a reason why nhc did not use the happy parser. (sidenote: compiling the happy parser using ghc takes ages and heaps of memory). > Our tracer assumes that "| Prelude.True" was added by the compiler and > does not insert any information about this guard into the Redex Trail. > There is, however, the danger that the original program actually > contained this guard. This may be a problem with automatically generated code which is more likely to use such odd guards than human programmers: I have seen this style of automatic code before. > I fear that you will have some problems with modifications of the syntax > tree, because you are interested in the result of the type checker. Our > tracing transformation is earlier. > Before the strongly connected component analysis, definitions for the > selectors for records are created. Also for some reasons unkown to me > the arity of method definitions is changed to match the number of ->'s > occuring in the type. During type checking do-notation and record > expressions are desugared. The type checker inserts the dictionaries for > the class mechanism. So there are lots of changes to the syntax tree. Yes this is a problem. > Well, because an identifier may occur in several forms, I am not sure > how such an un-rename function could be useful. I think I didn't express that very well in my last email. What I was looking for was a function that given an identifier (and its src position) you could find out what it got renamed to (thus use the renamed version to look up information in the symbol table). I'm assuming that all of the different forms that an identifier has in a module get renamed to the same thing. As for the matter of printing useful error messages during type checking: that is a different story. > I'm fairly new to nhc as well, started working on it in June. > Do you use the latest CVS version? No, I'm just using the tarball from the web page. > Admittedly, it may not always work, > but I am constantly adding lots of type definitions, type declarations > and comments. Ah! That would be very nice. I have noticed a distinct lack of type declarations and comments. Although Haskell code without comments is far better than C code without comments :) One thing that I think would really improve the nhc source (and this is probably related to the lack of abstract data types) is to bury some of the state into a monad. There is a lot of state threading that could be cleaned up with a state monad. Of course this always takes time and there are probably more important matters to deal with first. I must say that I am very impressed with the speed with which nhc compiles code. Thanks again. Bernie.