haberman / gazelle
- Source
- Commits
- Network (4)
- Issues (0)
- Downloads (4)
- Wiki (1)
- Graphs
-
Tag:
v0.3
gazelle / ReleaseNotes
| dc02e9b3 » | haberman | 2008-06-27 | 1 | ||
| e9bcdeef » | haberman | 2008-11-30 | 2 | Gazelle 0.3, released November 30, 2008 ======================================= | |
| 708597c2 » | haberman | 2008-09-29 | 3 | ||
| 4 | Overview: This release represents a lot of work on Gazelle's grammar analysis | ||||
| 5 | and lookahead generation. What this means for users is that many many cases | ||||
| 6 | where Gazelle would previously hang or generate incorrect grammar have been | ||||
| 7 | fixed, and there are lots of unit tests to ensure these don't break in the | ||||
| 8 | future. There is also one new feature: explicit ambiguity resolution. | ||||
| 9 | |||||
| 10 | Core Parsing Algorithm: | ||||
| 11 | * Gazelle now detects many errors in grammars: | ||||
| 12 | - left-recursion | ||||
| 13 | - rules that have no non-recursive alternative | ||||
| 14 | - grammars that are probably not LL(*) (using a heuristic) | ||||
| 15 | * Gazelle now supports many LL(*) grammars (that have cyclic GLA's) in | ||||
| 16 | addition to LL(k). This puts us on par with ANTLR. | ||||
| 17 | * It is no longer possible to make Gazelle hang by feeding it the wrong | ||||
| 18 | grammar. Since the problem of whether a grammar is LL(*) is undecidable | ||||
| 19 | in general, Gazelle gives you two options for how to bound the amount of | ||||
| 20 | work. You can either use a heuristic to detect cases where the grammar | ||||
| 21 | is probably not LL(*), or you can specify a bound on k. | ||||
| 22 | * The generated lookahead can now take EOF into account, which allows us to | ||||
| 23 | support grammars where we don't know what alternative to take until we see | ||||
| 24 | EOF. | ||||
| 25 | |||||
| 26 | New Features: | ||||
| 27 | * Grammar files now support C-style comments: // and /* */. | ||||
| 28 | * Explicit ambiguity resolution allows grammar authors to specify priorities | ||||
| 29 | between alternatives that would otherwise be ambiguous. The need for this | ||||
| 30 | arises in cases like the famous "if-then-else" problem, which is inherently | ||||
| 31 | ambigous but has a rule for how this ambiguity should be resolved. | ||||
| 32 | |||||
| 33 | Backward Incompatibilities: | ||||
| 34 | * All regular expressions that are defined within rules (as opposed to being | ||||
| 35 | named beforehand) must now be named within the rule. For example: | ||||
| 36 | |||||
| 37 | a -> /foo/; | ||||
| 38 | |||||
| 39 | ...is no longer allowed, you must write: | ||||
| 40 | |||||
| 41 | a -> .foo=/foo/; | ||||
| 42 | |||||
| 43 | It's important that regular expressions get a reasonable name. Also, | ||||
| 44 | unnamed regular expressions conflict with the new syntax for prioritized | ||||
| 45 | choice. | ||||
| 46 | |||||
| 47 | Caveats: | ||||
| 48 | * Although the compiler supports EOF in lookahead, proper support has not | ||||
| 49 | been added to the runtime yet. | ||||
| 50 | * There's still no way to ignore whitespace yet. This will hopefully come | ||||
| 51 | in the next release. | ||||
| 52 | |||||
| 1d59ede8 » | haberman | 2008-06-29 | 53 | Gazelle 0.2, released June 29, 2008 =========================================== | |
| dc02e9b3 » | haberman | 2008-06-27 | 54 | ||
| 55 | Overview: This is a major overhaul of Gazelle's guts. It also has | ||||
| 56 | significant usability improvements in its documentation and command-line | ||||
| 57 | tools. It is the first release of Gazelle I would actually recommend | ||||
| 58 | that people try out. | ||||
| 59 | |||||
| 60 | Core Parsing Algorithm: | ||||
| 61 | * The compiler now calculates true Strong-LL(k) lookahead. As a result, | ||||
| 62 | it supports far more grammars than Gazelle 0.1 did. | ||||
| 63 | * The runtime component now represents all of its state explicitly in its | ||||
| 64 | stack. As a result, parsing can be interrupted and resumed on arbitrary | ||||
| 65 | byte boundaries. | ||||
| 66 | * The "ignore" feature was completely removed, because experience and deeper | ||||
| 67 | thought revealed that it was not the right abstraction. As a result, this | ||||
| 68 | version of Gazelle has no way to deal with arbitrary whitespace. A | ||||
| 69 | replacement feature will come in the future to fill this gap. | ||||
| 70 | |||||
| 71 | Usability: | ||||
| 72 | * There is a manual (though very much in-progress). | ||||
| 73 | * The compiler is easier to invoke and has useful --help. | ||||
| 74 | * The compiler is capable of dumping a visual representation of the grammar | ||||
| 75 | to HTML if graphviz is installed. | ||||
| 76 | * gzlparse can dump the parse tree into JSON format. | ||||
| 77 | |||||
| 78 | Caveats (all of these will be fixed sooner or later): | ||||
| 79 | * The language and all APIs are still very much subject to change. | ||||
| 80 | * The current release cannot handle whitespace/comments/etc. in languages. | ||||
| 81 | * Parse errors will exit the program, instead of being reported to the API. | ||||
| 82 | * There are lots of edge cases the compiler doesn't properly deal with yet. | ||||
| 83 | Some will make the compiler go into an infinite loop, others will cause | ||||
| 84 | it to generate incorrect output. | ||||
| 85 | |||||
| 86 | Gazelle 0.1, released December 16, 2007 ======================================= | ||||
| 87 | |||||
| 88 | Overview: This is a preliminary release of Gazelle, and is not very usable. | ||||
| 89 | It can parse only a very small class of languages, and all tools/APIs are | ||||
| 90 | very rough around the edges. | ||||
| 91 | |||||
| 92 | Core Parsing Algorithm: | ||||
| 93 | * The supported lookahead is weak: only Simple-LL(1) parsing. | ||||
| 94 | * The runtime is reasonably fast and has a very low memory footprint. | ||||
| 95 | * The compiler and runtime support loading and storing the compiled version | ||||
| 96 | of the grammar to bytecode. | ||||
| 97 | |||||
