George Russell writes:
> Simon Peyton-Jones wrote:
> [snip]
> > There is no difficulty in principle here, but GHC would
> > have to retain a lot more location information than it
> > currently does. In particular, it could retain precise
> > location info for every occurrence, and propagate that
> > right through to the type checker. Do-able, but not easy to do.
> I hope I will not tread on too many corns if I say that a complete
> rewrite of GHC's parser (at least) is long overdue.
Eeek! I've just rewritten it! And I don't plan to do that again for a long
time :-)
> It is really
> appalling that
> (a) there is no error-correction.
Nonsense. I contend that you really don't want an error-correcting parser.
- parsing is quick
- error-correction is by definition unreliable
- error-correction is hard to implement well
you might think a good policy is "if you find a parse error, just read up to
the next semicolon & carry on", but layout totally screws this idea. You
often can't tell whether the next definition belongs to the current scope or
some other scope, and if you get out of step everything goes wrong.
We *do* have an error-correcting renamer and typechecker, on the other hand.
These are much easier - eg. if you find a type error in a given definition,
you can just assign it the type (forall a . a) for the remainder of the
compilation.
(I presume this is
> because the parser
> tries to be pure and so all errors result in the non-returning
> "error" function.)
Not really; I've been considering putting the whole parser in the IO monad
and using exceptions. "I'm not too proud to use global variables" :-)
> (b) locations of errors are often several lines away from
> the actual error.
Conceded. There are two causes of this:
1. Bugs, and
2. Not tracking the line number of every single token
(we only save the line number at certain places - eg.
the start of a definition, a case branch etc.)
Please send me any examples of (1). Examples of (2) are harder to fix,
because they require changing the abstract syntax.
> (c) the parser is so slow.
Disagree. I think it's nice & fast. I challenge you to write a faster
Haskell parser using a combinator library.
Besides, the time taken to parse a module is tiny compared to the rest of
the compilation time.
However, GHC's interface file parser is another matter - every compilation
needs to read several thousand lines of interface files, which is why you
see a second-or-so pause in the reader at the start of every compilation.
It's on my ToDo list to look at this sometime.
> The other suggestion made of having publicly available
> modules for Haskell
> syntax seems like a good one, and could be combined with this.
There's a freely available haskell parser library - take a look at
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne/haskell_libs/hsp
arser.html
Cheers,
Simon
