Invisible wrote:
> I think perhaps the best thing would be to perform this transformation 
> first, and only then attempt to do the actual parsing. The explicitly 
> delimited stuff looks a damn site easier to parse.

They're isomorphic. They are, by definition, exactly as easy to parse. :-)

But yes, the fact that you can go back and forth is one way to know it's not 
"context sensitive".  "Context sensitive" means something like "assignment 
means something different if it's in the 'else' part of the 'if' instead of 
the 'then' part."  Sort of like the difference between lexical scoping and 
textual scoping.

> Of course, the fun part is now trying to relate the location of any 
> parse errors back to the original source code. Indeed, with everything 
> I've done so far, it seems that making it *work* is relatively easy, but 
> making it give useful error messages if the user makes a mistake is 
> drastically harder.

Embed non-Haskell codes for line numbers.

[@1] foo x = [@2] case x of [@3] {1 -> "one"; [@4] 2 -> "two";
    [@5] 3 -> "three"}

> The only significant point is that this prevents you writing a 
> stand-alone Haskell parser; it can't be done. You can't parse Haskell 
> without comprehending it.

Depends what you mean by "parse" and "comprehend", but yes, I know what you 
mean. You can parse tokens, and you can only build a parse tree if you have 
the definitions. But that's true of almost any language; it's certainly true 
of any language where you'd talk about a parse tree. It's just that most of 
those languages have hard-coded operators, precedences, etc. They're just in 
a table in the compiler instead of in the source code.

You need to parse it into a map from symbol to definition, then figure out 
what order to parse the definitions in, yes?

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message