Brent --
Clever points are relatively high here, but I find the idea of
doing the notionally simultaneous parse uncomfortable. I really
don't want my programs subject to a hidden double parse cost.
Regards,
-- Gregor
On Wed, 2004-04-14 at 15:30, Brent 'Dax' Royal-Gordon wrote:
> Aaron Sherman wrote:
> > On Wed, 2004-04-14 at 09:29, Gregor N. Purdy wrote:
> >
> >>So, we are moving in a more verbose direction, which is a bummer for
> >>people who like to write one-liners and other tiny programs.
> >
> >
> > perl6 -i.bak -ple 'rule octet {\d{1,2}|<[01]>\d{2}|2[<[1-4]>\d|5<[1-5]>]}
> > s:g/\b<octet>\.<octet>\.<octet>\.<octet>\b/IP ADDR/;' *
> >
> > No biggie.
>
> Curlies aren't used for that anymore. I'd also suggest using an
> assertion for a much shorter C<octet> rule:
>
> perl6 -i.bak -ple 'rule octet {(\d<1,3>)<($1<256)>}
> s:g/\b<octet>\.<octet>\.<octet>\.<octet>\b/IP ADDR/' *
>
> TMTOWTDI, though, and I'm being rather nitpicky.
>
> Personally, I would implement Perl 5 vs. Perl 6 switching as:
>
> 1. If argv[0] includes either '5' or '6', use the appropriate version.
> 2. Parse the program as *both* Perl 5 and Perl 6.
> 3. Figure out which parses succeeded:
> a. If Perl 5 succeeded...
> i. If Perl 6 succeeded, emit an ambiguity warning. (I think this
> warning should be on by default, but that's open to
> negotiation.)
> ii. Execute the Perl 6 parse.
> b. Else if Perl 6 succeeded, execute the Perl 6 parse.
> c. Else...
> i. If exactly one of the parses died on an error that
> disambiguates between the Perls (e.g. a package statement, a
> 'use 6'), emit the other's error message.
> ii. Otherwise, emit an ambiguity warning and both error messages.
--
Gregor Purdy [EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
