> I don't think I quite understand the distinction. You mean that > something that looks like a haddock comment that appears in the wrong > place would cause an error, but an mis-formatting within a comment could > be just a warning?
Yes that's the distinction I'm talking about that could easily be made, but right now they both cause an error. > So you think we'd need something like an error correcting parser that > can discard the haddock comment token(s) if it is not expected in that > place in the grammar. Hmm, some parser libs can do that but not Happy as > far as I understand. Yes, something like that. Maybe not exactly high priority right now :) > So I'm guessing that your -haddock flag turns off the looking for the > comments at the lexer level? Exactly. >> The .hi-files are left untouched by these changes. The plan is to try to >> make haddock-ghc use the existing information in the .hi-files only, and >> it seems to work so far, at the expense of it having to do some work to >> recover information. >> >> Yes, the comments can now be accessed by using the GHC API. They are >> available both in the parsed and the renamed syntax. There is also some >> special per-module Haddock information available. > > Right. I guess one advantage of comments going into the .hi files would > be that they'd be accessible to GHCi and IDEs etc by only looking at > the .hi files and without having to parse the source again. Of course > that'd mean that haddock could also work only by looking at the .hi > files. The downside of course is more work to do and larger .hi files. Well, adding too much of this into the .hi-files would perhaps couple GHC too much with Haddock. For Haddock to truly make good use of the .hi-files we would have to put lots of things in them, things that Haddock only knows about after having massaged the comments and the rest of the data that it gets from the GHC API. This means that parts of the code in Haddock would have to be moved to GHC. Another idea could be to have Haddock save a per-package file (as the old one does), which could contain lots of useful data, readable by something like a Haddock API. External programs could load GHC API, then Haddock API and get access to that information. That would also simplify my writing of Haddock since I'm now desperately trying to recover information from the .hi-files that I've already actually computed when generating the docs for a package, but couldn't save then :) /David _______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
