--- Leif Frenzel <lfrenzel@...> wrote:
> Great :-) A parser is what we need most pressingly.
> I think the
> Language.Haskell stuff in the ghc sources will fit
> us fine.
> In the long run, we will need two parsers: a
> lightweight one that takes a
> source file and gives the main structural
> information (module name, imports,
> function names and types etc., that is, basically
> everything we want to be
> on the Outline view) and one that gives the complete
> AST (needed for search,
> refactoring etc.)
> If we can get the first of them (the lightweight
> one) running, we can do the
> compilation stuff and code assist. So I suggest that
> as the starting place.
> Thanks a lot && ciao,
Ok. Language.Haskell.Parser.parseModule gives us
As for the lightweight parser, I may be overseeing
something, but I think it wouldn't be hard to write,
even in Java. What complicates it are the layout
rules, or rather that there are 2 different ways to
describe the syntactical structure of a module
(explicit punctuation and layout). The parser could
apply the layout transformation rules and then parse
the result uniformly, but this implies making 2 passes
over a single module (transform, parse). But then, we
need to parse only toplevel declarations; the complete
parse would be the task of GHC's L.H.Parser module.
I think I'll experiment with both methods. Calling
GHC's parser module and returning just the topdecls
information shouldn't be hard, and then this could
grow up to a complete interface. At the same time,
I'll try to hack a simple toplevel parser in Java,
maybe with ANTLR, if I can get this to work quickly.
s, Andrei Formiga
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.