On Sat, Nov 05, 2005 at 11:45:02PM +0100, Autrijus Tang wrote: > I noticed that zero-length input is now rejected by <p6rules>; I tried > to fix it, but could not determine where the fix should go. A trace is > listed below: > > compilers/pge$ echo 'rule ' | parrot demo.pir > Missing term at offset 0 > current instr.: 'PGE::OPTable :: parse' pc 1483 > (compilers/pge/PGE/Exp.pir:134)
Handling parse errors in PGE is still something I'm working on, at the moment pge handles errors by throwing exceptions. This will probably be changed -- and there's two aspects to this I'm working on. First, for null input, PGE (and p6rules) will likely parse this by returning a Match object indicating "false", and attempting to compile that object will probably return a null subroutine. The other case is when there's an operator requiring a term and such a term isn't found -- i.e., an invalid expression such as "$a + 5 *". I can either have pge return the portion that successfully matches (i.e., the "$a + 5" part), return a false Match object, or throw an exception. At the moment I'm in favor of returning the portion that successfully matches, similar to what a rec-descent parser would do. > As a workaround, I special-cased m:// and m:P5// in Pugs, which may > be useful anyway, as split(//, $string) is quite common. If I read S05 correctly, that now has to be split(/<?null>/, $string). Thanks, Pm
