Re: Apoc 5 questions/comments
Damian Conway <[EMAIL PROTECTED]> outlined his plans for world domination: [...] > > Dammit, you fools! Do I have to think of *everything*??? Just tie him to a > steel bench and apply the Ruby laser! > > I do apologize, Mr Wardley. Good evil assistants are just impossible to get > these days. > Cut the Smalltalk. It's off-topic. -- Ariel Scolnicov
Re: Apoc 5 questions/comments
On Sun, Jun 09, 2002 at 03:34:16PM +1000, Damian Conway wrote:
> Trey Harris wrote:
> > rule val {
> > [ # quoted
> >$b := <['"]>
> >( [ \\. | . ]*? )
> >$b
> > ] | # or not
> >(\H+)
> > }
>
> Not quite. Assigning to $b is a capture.
I'm confused. The examples in A5 all show $var := (pattern). So are you
saying that parens or no, binding with := affects a capture into
$1,$2,etc.? Or that it affects a capture that alters the return value
of the rule, just not $1,$2,etc.?
A5 says:
Subrules called via also capture their result in
hypothetical variables. It's possible to name the results of any
<...>, but grammar rules already have a name by default, so you
don't have to give them names unless you call the same rule more
than once. So, presuming you have grammar rules defining "key"
and "value", you can say:
/ \: { let %hash{$key} = $value } /
So ... should this work?
rule quote { <["']> }
rule quotedword { (+) $quote }
$justtheword = //;
And if the above works, why can't "$var:=atom" be a short hand for a
lexical "rule var { atom }" that only applies for the current ... um ...
rule/? And thus the capture would be out
of band WRT $1, $2, etc. or the rule's return value.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Apoc 5 questions/comments
I assume that 'fatal.pm' is a new pragma. 1) What (if anything) does it do, aside from turning 'fail' into a fatal exception when used outside a regex? 2) Do you need to use it before you can (usefully) use 'fail' INSIDE a regex? (I would assume not, but thought I'd check.) Dave On Fri, 7 Jun 2002, Larry Wall wrote: > On Fri, 7 Jun 2002, Dave Storrs wrote: > > Just to be sure I understood: you meant that (A) yes, you can use > > fail in a subroutine outside a regex, and (B) if you do, it is no > > different from die. Is that correct? > > Depends on the caller's use of "use fatal". If they don't use fatal, > it returns undef. > > Larry > >
Re: Apoc 5 questions/comments
On Mon, 10 Jun 2002, Dave Storrs wrote: > > I assume that 'fatal.pm' is a new pragma. Already exists for Perl 5, actually. > 1) What (if anything) does it do, aside from turning 'fail' into a fatal > exception when used outside a regex? What fatal currently does is wrap built-ins that might return undef with code that will die when undef is returned. I'm just generalizing that to having a keyword that fails in whatever way the calling context desires, whether by returning undef, throwing an exception, or backtracking the current regex. > 2) Do you need to use it before you can (usefully) use 'fail' INSIDE a > regex? (I would assume not, but thought I'd check.) No, it'll be built-in. You'll only need to invoke the pragma to change the defaults. Larry
Re: Apoc 5 questions/comments
On Mon, 10 Jun 2002, Larry Wall wrote: > On Mon, 10 Jun 2002, Dave Storrs wrote: > > > > > I assume that 'fatal.pm' is a new pragma. > > Already exists for Perl 5, actually. *blush* Must have missed it. Drat, and I just finished rereading Camel III. Apologies. Dave
Re: Apoc 5 questions/comments
On Fri, 7 Jun 2002, Luke Palmer wrote: > > Dave Storrs wrote: > > Can we please have a 'reverse x' modifier that means "treat whitespace as > > literals"? Yes, we are living in a Unicode world now and your data could > > > > /FATAL ERROR\:Process (\d+) received signal\: (\d+)/ > > I don't see how this example is nearly as flexible as this: > > m:w/FATAL ERROR\: Process (\d+) recieved signal\: (\d+)/ > > Yours will only match 4 spaces after FATAL ERROR:, whereas mine will match > any number. [...] > I see the :w modifier as a good flexibility enforcement. It will > keep people away from matching things that very literally. Respectfully, Luke, I think you and I are discussing separate issues. You are talking about the best way to match multiple whitespace--and I agree with what you're saying, one should never assume that it will always be 4 spaces instead of 5. Were I writing that code in a real project, instead of as a demo for the list, I would use \s+ (in P5, anyway...in P6, whether I would use \s+ or \h+ would depend on circumstances). However, the point I was making was that, if I feel confident in only handling a limited subset of the possibilities because I know what I'm going to be getting (because, e.g., I wrote it out myself), then I would like a way to do away with the visual clutter involved in backwhacking or entity-izing every bit of whitespace. Perl has never been a nanny-language...one of its greatest strengths has always been that it trusts me to make my own decisions and, if I want to shoot myself in the foot, I can. :> The suggestions that other people have been making about defining subrules and then building them up in order to make the entire match are good, and in general that's a very powerful technique. However, the lines devoted to those subrules still count as visual clutter, and I'd still like a way to do away with them. Dave
Re: Apoc 5 questions/comments
Jonathan Scott Duff wrote:
> > > rule val {
> > > [ # quoted
> > >$b := <['"]>
> > >( [ \\. | . ]*? )
> > >$b
> > > ] | # or not
> > >(\H+)
> > > }
> >
> > Not quite. Assigning to $b is a capture.
>
> I'm confused. The examples in A5 all show $var := (pattern). So are you
> saying that parens or no, binding with := affects a capture into
> $1,$2,etc.? Or that it affects a capture that alters the return value
> of the rule, just not $1,$2,etc.?
The latter.
> So ... should this work?
>
> rule quote { <["']> }
> rule quotedword { (+) $quote }
> $justtheword = //;
My understanding is that it won't just return the word. If you invoke a named rule,
its return value is captured in a hypothetical variable of the same name (but *not*
into a numbered hypovar -- only parens do that). The named hypovar lives inside the
object that is ultimately returned to the next level up.
So C returns (what appears to be) a simple string to C,
but -- because of the captures it does -- C returns an object with
embedded C<$quote> and C<$alpha> hypovars.
> And if the above works, why can't "$var:=atom" be a short hand for a
> lexical "rule var { atom }" that only applies for the current ... um ...
> rule/? And thus the capture would be out
> of band WRT $1, $2, etc. or the rule's return value.
As explained above, named captures *are* out-of-band wrt $1, $2, etc.
Just not wrt to the return value.
As I mentioned in a previous post, the issue is how to control what a given
(sub-)rule returns (i.e. all its explicit and captures, or just a specific
result). I think the correct answer is to control that explicitly, via a
assertion or a $RETURN:= capture.
Damian
A5 - A job well done
Larry, Wow, that was a very good demolition and rebuilding of the regex edifice. When the RFCs were being written I spent many hours thinking over some of the issues and writting many of the RFCs on regexes, trying to build on what was in perl5, without changing the existing language use. By allowing change to that starting point he has done a much better job of it. (I was not a novice in this as I had done research in pattern matching at University many many years ago) At the time of the RFCs I was employed and hence had more free time to spend thinking about the design of perl6 than I do at present. (How is it that being unemployed I have LESS free time...) Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecommunications Consultant, ATM expert, Web Analyst & Services
