Olaf Chitil (olaf@cs.york.ac.uk)
Tue, 22 Aug 2000 11:27:33 +0100
Hi Bernie, > 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 admit that this would be nice. It would, however, already be a lot of work to change nhc, because nearly every module pattern matches on the syntax tree. Also I am not sure if HsSyn would be suitable for nhc. Nhc uses the same data structure for the syntax tree throughout the whole compiler until code generation. Hence the syntax tree data structure provides some facilities that are only needed for some compiler phases. > 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). Well, first of all nhc is much older than happy. The earlier versions of ghc used some terrible interface to a yacc parser. According to Malcolm, nhc cannot compile parsers generated by happy. He didn't investigate much who's fault that is. Earlier versions of happy definitely had problems with producing portable Haskell code. However, I think that parser combinators are much more convinient to use (no hassle with another program) and I don't believe that they are that inefficient (at least not the ones in nhc). > > [...] So there are lots of changes to the syntax tree. > > Yes this is a problem. Others I remember now: The renamer removes type synonym definitions and replaces data and newtype definitions by an internal DeclConstrs declaration. Before strongly connected component analysis class and instance declarations are replaced by their type and method declarations. > > 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). Well, the renaming phase builds lists of renaming tables to map tokenIds (names appearing in source) plus idKind (constructor, variable,...) to the internal unique identifier. However, lists are used to deal with scoping, no position. It should be possible to build a function as you desire it at the same time. However, there is also the issue of overlap resolution. I don't know how that works. By the way, I am not sure that nhc produces meaningful types for local identifiers in the symbol table. I don't see how it could represent type variables that are bound in a surounding scope. > I'm assuming that all of the > different forms that an identifier has in a module get renamed to the same > thing. Yes, although I think that this is not quite correct for method names and field names. There seem to be different identifiers for methods in type declarations, default definitions and instance definitions. There are als different identifiers for field names as selectors and for construction/updating. I haven't yet worked out all the details. > As for the matter of printing useful error messages during type > checking: that is a different story. Yes. The current error messages are terrible. > 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 :) I fear Niklas Rojemo did not only want a compiler that produces space efficient programs and that itself is space efficient, but the compiler should also have less than 10000 lines of code, including comments. Not including any type declarations and comments seemed to help towards this goal ;-(. I have different priorities. > 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. The State type is basically a reader state monad. However, the code using it could be much clearer. I already introduced type synonyms to make it clearer and at some point I hope to switch to a real monad with do notation. > I must say that I am very impressed with the speed with which nhc > compiles code. It would be interesting to compare nhc with ghc without optimisations. In which phases is one faster than the other and for which reason? Cheers, Olaf -- OLAF CHITIL, Dept. of Computer Science, University of York, York YO10 5DD, UK. URL: http://www.cs.york.ac.uk/~olaf/ Tel: +44 1904 434756; Fax: +44 1904 432767