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/
