Skip to content

Latest commit

 

History

History
124 lines (79 loc) · 3.07 KB

TODO.org

File metadata and controls

124 lines (79 loc) · 3.07 KB

Generalise CMakefile [%]

Platform independent flags

A few working examples of parsers

Add documentation

Fix error messages [%]

[#C] Customization

I think we need to allow the user to customize error messages.

One solution would be:

  1. standard, very basic error msg for sequence, alternatives, etc. (like, “unrecognized element in sequence”)
  2. Customizable error messages (like: expecting x).

This is low priority now.

[#A] TIPA: Add a symbolic description for a terminal rule

<2020-02-14 ven.>

  • When an error in a sequential rule is detected, print the name of the rule. For example:

    ”@[10:5] list a, b, c;” ” -----^” “Error 123: Expecting {“,

    In case of a simple rule that accepts a string, by default the name of the rule is the same as the string. In case of a token, it is not the case to print the regular expression, so we can add a symbolic name.

[#C] TIPA: Reduce error noise

Change the interface to the error reporting. It must be possible to eliminate some previous reporting errors, or to “resume” them.

For example, in case of alternate rule, we could simply print the following:

”@[10: ] 123 $ 234” ” ----^” “Error 124: Unrecongnized token, expecting:” ” ‘+’, ‘-‘, ‘*’, ‘/’ ”

Right now, it prints a lot of stuff (one for each possible terminal rule in the alternative).

Backtracking

Of course, we need a better way to signal the point in which the message was found. To do this, I need to:

  1. Store the first point at which I find an error
  2. Backtrack
  3. If this causes an error at a higher level, store the new point, and backtrack until,
    • either we find an alternative path: in this case, we just drop the entire stack of errors
    • or, we reach the top level, in this case we just return “false”.

This is rather urgent, otherwise the parser is almost unusable.

[#B] Optimizing the graph structure [%]

Sequences

Like alternatives, it would be nice to compact a long sequence in a single rule, this simplifies a lot of things.

How do we do this ?

rule x = a >> b >> c;

Currently it is transformed into:

 x --> seq --> c 	
	    |
	    +--> seq --> a
		  |
		  +--> b

I would like to have

x --> seq --> a 
	    |
	    +--> b
	    |
	    +--> c

To do this during construction I need to do the following:

  • build a seq_rule
  • see if one of the two elements is a sequential rule:
  • if so,
    • take the elements and integrate them directly, at the right position in the vector
    • delete one of the two elements (thanks to shared pointers, that should be automatic)

Notice that class seq_rule already supports long sequences, because it stores everything in a vector< WPtr<impl_rule> >.