On 11/6/05, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > 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.
Yes, that sounds sane. > 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. This too, as you can trivially concat the OPTable parser with an explicit end-of-string marker. > > 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). Indeed. It's fortunate that there is a split('', $string) form. ;-) Empty rules are now an error in Pugs. Thanks for the correction! /Autrijus/