Changes between Version 6 and Version 7 of Commentary/Parser

Timestamp:

08/18/09 12:51:47 (4 years ago)

Author:

benl (IP: 150.203.160.45)

Comment:

--

Commentary/Parser

@@ -5 +5 @@
 The parser has two main goals; to build an AST for the compiler and to give good syntax errors for the compiler user.
 
-To meet the second goal, good parser error messages, the use of Parsec.try should be avoided. Parsec.try is problematic because:
+== Avoid using the try combinator ==
+To generate good parser error messages, the use of Parsec.try should be avoided. Parsec.try is problematic because:
 
  - The process of starting at the try, parsing forward, failing and then backtracking is slower than parsing with only a single token lookahead.
@@ -14 +15 @@
           x = [ x + 2, y | x <- [ 1, 2, 3, 4 ]]
       }}}
-   the parser would get to the '|' token, fail and backtrack to the '=' token. When all other parser combinators also fail, the parser would flag an error at the '=' token. The try-less parser on the other hand would correctly flag the error at the '|' token.
+ the parser would get to the '|' token, fail and backtrack to the '=' token. When all other parser combinators also fail, the parser would flag an error at the '=' token. The try-less parser on the other hand would correctly flag the error at the '|' token.
 
-Furthermore, try-less parsing should not make the parser any more difficult to modify or extend. Quite the contrary, the try-less parser is easier debug and easier to extend once the concepts of try-less parsing are understood.
+In general, try-less parsing should not make the parser any more difficult to modify or extend. 
 
 As an example, a part of the expression parser (src/Source/Parser/Exp.hs) used to look like this