Re: Regex query
SC == Simon Cozens [EMAIL PROTECTED] writes:
SC raiddev /dev/md0
SC raid-level 5
SC option value
SC option value
SC ...
SC device /dev/sde1
SC raid-disk 0
i have some comments/questions as i am trying to learn this myself. i
could be way off base but here goes:
SC grammar Raidtab;
SC rule raidtab { raiddev+ };
SC rule comment { sp* \# .* |
shouldn't that . be \N so it won't eat the next line or even beyond?
also you have sp* here and sp* below. i think the latter is correct.
SC# Or a blank line
SC^^ \n };
shouldn't that have a sp* inside the blank line?
SC rule comm_eol { sp* comment? sp* \n };
aren't those sp*'s redundant? the first is overlapping with the one at
the beginning of comment. and the second is subsumed by the .* at the
end of comment.
SC rule raiddev { comment*
i think that should be comm_eol as you want to skip all full comment lines.
SCsp* raiddev sp+ $name := (/dev/md\d+) comm_eol
SC (devicelayout | option | comment)+ };
same as above, comm_eol instead of comment.
SC rule option { sp* $key := ([a-z]-+) sp* $value := (\w+) comm_eol };
i think that char class should be [a-z-]. [] marks a class and the -
needs to be inside it.
the second sp* should be sp+ as you need whitespace between the
option and value.
SC rule devicelayout { sp* device sp+ $name := (/dev/\w+) comm_eol
the \w+ after /dev/ needs to be more accepting as i think some devices
could be in subdirs
SC sp* $type := (raid|spare|parity) -disk sp*
SC $index := (\d+) comm_eol
SC };
SC What I can't figure out is how to drill down into the returned match
SC object and get at individual devices. I'd expect to be able to say
SC something like
SC $matchobject{raiddev}[0]{devicelayout}[1]{name}
SC and get /dev/sdf1. Is that how it works, with multiply-matched rules
SC being put into arrays, or is it stored differently somehow?
that is how i understand it. the grammar automatically build a tree of
the grabs with hash keys being the rule names and multiples (rules with
quantifiers) being arrays.
what about the case where you have a descending set of rules but no
quantifiers. would you just not have the [0] parts when you access it
from the match object?
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Re: Regex query
SC == Simon Cozens [EMAIL PROTECTED] writes:
SC rule comm_eol { sp* comment? sp* \n };
aren't those sp*'s redundant? the first is overlapping with the one at
the beginning of comment.
SC But comment only matches if there *is* a comment, and there may not
SC be, so I want to match optional space at the EOL anyway.
ok, but since comment is optional, if it doesn't match, the two sp*
are back to back. is that needed? i just see too many sp* and that
could lead to backtracking issues (something i recall from MRE1).
SC rule raiddev { comment*
i think that should be comm_eol as you want to skip all full comment lines.
SC I thought the .* (or \N*) would skip the whole line. comm_eol just means
SC comment at end of line.
i figured that was what it meant. but . matches any char now so .* will
eat all the text until it is forced to backtrack. so \N* will stop at
the newline which is what i think you want in comm_eol.
that is how i understand it. the grammar automatically build a tree of
the grabs with hash keys being the rule names and multiples (rules with
quantifiers) being arrays.
SC Great.
actually i just had another thought. you don't need any of the $foo :=
stuff as the match tree will have it all for you. unless you need a
single var having some grabbed stuff, you might as well let the match
object hold it all. you do want a tree from this parser so the single
vars will do no good. unless they also put stuff into the tree based on
their names. also if you use a scalar to grab something which is in a
quantified outer rule what is put in the var? a ref to a list of the
grabbed things?
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Re: Regex query
[EMAIL PROTECTED] (Uri Guttman) writes:
actually i just had another thought. you don't need any of the $foo :=
stuff as the match tree will have it all for you.
Yes, but it's nice to be able to access the captured things by
name. Or should I be saying things like
rule raiddev { comment*
sp* raiddev sp+ name comm_eol
(devicelayout | option | comment)+ };
rule name { /dev/md\d+ }
their names. also if you use a scalar to grab something which is in a
quantified outer rule what is put in the var? a ref to a list of the
grabbed things?
*nod* Something I'd like to know.
--
Even if you're on the right track, you'll get run over if you just sit there.
-- Will Rogers
Re: Regex query
SC == Simon Cozens [EMAIL PROTECTED] writes:
SC [EMAIL PROTECTED] (Uri Guttman) writes:
actually i just had another thought. you don't need any of the $foo :=
stuff as the match tree will have it all for you.
SC Yes, but it's nice to be able to access the captured things by
SC name. Or should I be saying things like
SC rule raiddev { comment*
SCsp* raiddev sp+ name comm_eol
are the quotes there literals? they aren't in the file format i think.
SC (devicelayout | option | comment)+ };
SC rule name { /dev/md\d+ }
yeah, that should grab name in the match object as a hash element of the
raiddev level. or maybe it needs grab markers somewhere? i am not sure
it should be (name) in the raiddev rule or (/dev/md\d+) in the name
rule. both could work but give different places where the grab ends up.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Re: Regex query
On 20 Sep 2002, Simon Cozens wrote: : their names. also if you use a scalar to grab something which is in a : quantified outer rule what is put in the var? a ref to a list of the : grabbed things? : : *nod* Something I'd like to know. Yes, in fact any list forced into scalar context will make a ref in Perl 6: $arrayref = (1,2,3); Larry
Re: hotplug regexes, other misc regex questions
On Sun, 15 Sep 2002, Steve Fink wrote:
: What should this do:
:
: my $x = the letter x;
: print yes if $x =~ /the { $x .= ! } .* !/;
Depends. I think it may be necessary for speed and safety reasons
to set COW on the string we're matching, so that you're always matching
against the original string. Perhaps we can make it work in the specific
case of concatenation, since we want to it to work for extensible
strings coming from a filehandle. But if a fast implementation needs to
keep pointers into a string rather than offsets from the beginning,
we're asking for core dumps if the string is modified out from under the
pointers, or we have to adjust all known pointers any time the string
may be modified.
: Does this print yes?
:
: print yes if helo =~ /hel { .pos-- } lo/;
Yes, that isn't modifying the string.
: Would it be correct for this to print 0? Would it be correct for this
: to print 2?
:
: my $n = 0;
: aargh =~ /a* { $n++ } aargh/;
: print $n;
:
: It might want to print zero because if regexes are not required to pay
: attention to modifications in the input string, then it can optimize
: away the a*.
Implementation dependent, but there will probably be a :modifier to
specifically turn off optimizations.
: What possible outputs are legal for this:
:
: aaa =~ /( a { print 1 } | a { print 2 })* { print \n } x/
Lots. :-)
Larry
Re: Regex query
On Fri, 2002-09-20 at 04:14, Larry Wall wrote: On 20 Sep 2002, Simon Cozens wrote: : their names. also if you use a scalar to grab something which is in a : quantified outer rule what is put in the var? a ref to a list of the : grabbed things? : : *nod* Something I'd like to know. Yes, in fact any list forced into scalar context will make a ref in Perl 6: $arrayref = (1,2,3); Is that any list as oppopsed to any array? Or is that arrayref in a numeric context the length of the array? In other words does this do what I think I think it does? $shouldbe3 = (1,2,3) + 0; -- Aaron Sherman [EMAIL PROTECTED]
RE: Passing arguments
On Thu, 19 Sep 2002, Brent Dax wrote:
: Aaron Sherman:
: # topicalize: To default to C$_ in a prototype (thus
: # acquiring the caller's current topic).
:
: Well, to topicalize a region of code is actually to specify a different
: topic, that is, a different value for $_. For example:
:
: $foo = new X;
: $bar = new Y;
:
: given $foo {
: print $_.type, \n;#prints X
:
: given $bar {
: #XXX we're using 'given' for this too, right?
: print $_.type, \n;#prints Y
: }
: }
Yes.
: (An aside: it strikes me that you could use Cgiven as a scoped lexical
: alias, i.e.
:
: my $foo=foo;
: my $bar=bar;
:
: print $foo;
:
: given $bar - $foo {
: print $foo;
: }
:
: print $foo;
:
: #prints foobarfoo
:
: Hmm...)
Sure, though it also aliases to $_.
: # signatureless sub: A sub that does not specify a prototype,
: # and thus has a default prototype of:
: #
: # sub($_//=$_){};
: #
: # ne?
:
: More like:
:
: a sub that was created with the arrow (-) or a bare block and
: does not specify a prototype, and thus has a default prototype
: of:
:
: - ($_ //= $OUTER::_) { };
OUTER only works for lexical scopes. What you want is out-of-band access
to the $_ in the surrounding dynamic context
: Or some such. (Maybe C$_ //= $_ will work, but I have reservations
: about that--especially about the possibility of that picking up $_
: dynamically instead of lexically. In some cases you want $_
: dynamically, in others lexically. Perhaps C$_ is topic('lexical') and
: C$_ is topic('dynamic')?)
The current thinking as of Zurich is that the given passes in
separate from the ordinary parameters:
sub ($a,$b,$c) is given($x) {...}
That binds the dynamically surrounding $_ to $x as an out-of-band
parameter. Can also bind to $_ to make it the current topic.
Not sure of the syntax for pointy subs yet. Maybe
- ($a,$b,$c) is given($x) {...}
Larry
Re: Regex query
On 20 Sep 2002, Aaron Sherman wrote: : Is that any list as oppopsed to any array? Or is that arrayref in a : numeric context the length of the array? In other words does this do : what I think I think it does? : : $shouldbe3 = (1,2,3) + 0; It's 3, though not for the reason a Perl 5 programmer would think. (In Perl 6 it's the length of the anonymous array, not the last value.) Larry
RE: Passing arguments
Larry Wall:
# That binds the dynamically surrounding $_ to $x as an
# out-of-band parameter. Can also bind to $_ to make it the
# current topic.
The problem I have with that is this:
sub for_trace(*@array, block) {
loop($_=0; $_ @array; $_++) {
print $_:\n;
{
my $coreprint=CORE::print;
my $lastnl=1;
temp CORE::print := sub ($fh: *@args) {
$fh.$coreprint(\t) if $lastnl;
$fh.$coreprint(@args);
$lastnl = @args[@args.last] =~
/\n $/;
}
block(@array[$_]);
}
print \n
}
}
$_=x;
@list=qw(y z);
for_trace @list - $x {
print $_;
}
Which of these does this print?
0:
0
1:
1
0:
y
1:
z
0:
x
1:
x
The correct behavior (IMHO) is the third, though I could see the
second. But the first is unacceptable.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
RE: Passing arguments
On Fri, 2002-09-20 at 10:36, Larry Wall wrote:
On Thu, 19 Sep 2002, Brent Dax wrote:
: (An aside: it strikes me that you could use Cgiven as a scoped lexical
: alias, i.e.
: given $bar - $foo {
: print $foo;
: }
Sure, though it also aliases to $_.
Does that mean that I can't
for $x - $_ {
for $y - $z {
print $_, $z\n;
}
}
And expect to get different values?
: # signatureless sub: A sub that does not specify a prototype,
: # and thus has a default prototype of:
: #
: # sub($_//=$_){};
: #
: # ne?
:
: More like:
:
: a sub that was created with the arrow (-) or a bare block and
: does not specify a prototype, and thus has a default prototype
: of:
:
: - ($_ //= $OUTER::_) { };
OUTER only works for lexical scopes. What you want is out-of-band access
to the $_ in the surrounding dynamic context
I assumed that's what C//=$_ was. It does have the disadvantage of
looking like variable assignment, though.
The current thinking as of Zurich is that the given passes in
separate from the ordinary parameters:
sub ($a,$b,$c) is given($x) {...}
Ok, that seems saner.
That binds the dynamically surrounding $_ to $x as an out-of-band
parameter. Can also bind to $_ to make it the current topic.
Not sure of the syntax for pointy subs yet. Maybe
- ($a,$b,$c) is given($x) {...}
I was with you up until this last example. Can you give a surrounding
context so I can see how that would be used?
--
Aaron Sherman [EMAIL PROTECTED]
Re: Regex query
On Fri, 2002-09-20 at 10:39, Larry Wall wrote: On 20 Sep 2002, Aaron Sherman wrote: : Is that any list as oppopsed to any array? Or is that arrayref in a : numeric context the length of the array? In other words does this do : what I think I think it does? : : $shouldbe3 = (1,2,3) + 0; It's 3, though not for the reason a Perl 5 programmer would think. (In Perl 6 it's the length of the anonymous array, not the last value.) Yes, sorry for the bad example. That's what I meant. -- Aaron Sherman [EMAIL PROTECTED]
RE: Passing arguments
On Fri, 20 Sep 2002, Brent Dax wrote:
: Larry Wall:
: # That binds the dynamically surrounding $_ to $x as an
: # out-of-band parameter. Can also bind to $_ to make it the
: # current topic.
:
: The problem I have with that is this:
:
: sub for_trace(*@array, block) {
: loop($_=0; $_ array; $_++) {
: print $_:\n;
:
: {
: my $coreprint=CORE::print;
: my $lastnl=1;
:
: temp CORE::print := sub ($fh: *@args) {
: $fh.$coreprint(\t) if $lastnl;
:
: $fh.$coreprint(args);
:
: $lastnl = args[@args.last] =~
: /\n $/;
: }
:
: block(array[$_]);
: }
:
: print \n
: }
: }
:
: $_=x;
: list=qw(y z);
:
: for_trace list - $x {
: print $_;
: }
:
: Which of these does this print?
:
: 0:
: 0
: 1:
: 1
:
: 0:
: y
: 1:
: z
:
: 0:
: x
: 1:
: x
:
: The correct behavior (IMHO) is the third, though I could see the
: second. But the first is unacceptable.
The rule says the innermost topicalizer wins, and pointy sub always
topicalizes its first argument, so the second behavior is what happens.
The third behavior can always be forced with $OUTER::_. But it would
be better stylistically to name it something other than $_--which is
part of the reason we decided to make the topicalizers always alias
$_ in addition to whatever else they might alias. It's much better
to keep the pronouns referring to small-scale topics rather than
large scale.
Larry
Re: hotplug regexes, other misc regex questions
On Fri, 20 Sep 2002, Larry Wall wrote: But if a fast implementation needs to keep pointers into a string rather than offsets from the beginning, we're asking for core dumps if the string is modified out from under the pointers, or we have to adjust all known pointers any time the string may be modified. With the current Parrot GC, keeping pointers into the string while doing unrelated allocation will get you a core dump, since the string body might be copied. So unless the regex engine copies strings off into its own private non-collected storage, we're stuck with offsets anyways. /s
RE: Passing arguments
On 20 Sep 2002, Aaron Sherman wrote:
: On Fri, 2002-09-20 at 10:36, Larry Wall wrote:
: On Thu, 19 Sep 2002, Brent Dax wrote:
:
: : (An aside: it strikes me that you could use Cgiven as a scoped lexical
: : alias, i.e.
: : given $bar - $foo {
: : print $foo;
: : }
:
: Sure, though it also aliases to $_.
:
:
: Does that mean that I can't
:
: for $x - $_ {
: for $y - $z {
: print $_, $z\n;
: }
: }
:
: And expect to get different values?
That's correct. Name the outer topic explicitly, not the inner one.
: : # signatureless sub: A sub that does not specify a prototype,
: : # and thus has a default prototype of:
: : #
: : # sub($_//=$_){};
: : #
: : # ne?
: :
: : More like:
: :
: : a sub that was created with the arrow (-) or a bare block and
: : does not specify a prototype, and thus has a default prototype
: : of:
: :
: : - ($_ //= $OUTER::_) { };
:
: OUTER only works for lexical scopes. What you want is out-of-band access
: to the $_ in the surrounding dynamic context
:
:
: I assumed that's what C//=$_ was. It does have the disadvantage of
: looking like variable assignment, though.
I don't think we want to allow binding of defaults to variables of
the outer lexical scope. $_ is kind of special that way.
: The current thinking as of Zurich is that the given passes in
: separate from the ordinary parameters:
:
: sub ($a,$b,$c) is given($x) {...}
:
:
: Ok, that seems saner.
:
: That binds the dynamically surrounding $_ to $x as an out-of-band
: parameter. Can also bind to $_ to make it the current topic.
:
: Not sure of the syntax for pointy subs yet. Maybe
:
: - ($a,$b,$c) is given($x) {...}
:
: I was with you up until this last example. Can you give a surrounding
: context so I can see how that would be used?
Exactly the same as the previous example.
Larry
Re: Regex query
On Fri, 20 Sep 2002, Larry Wall wrote: Yes, in fact any list forced into scalar context will make a ref in Perl 6: $arrayref = (1,2,3); That would seem to obviate the need for brackets to define array references. Is there any case where [1,2,3] would be needed instead of (1,2,3)? Also, does any list include a list of pairs? Because that would look more like a hash than a list. $ref = ( one = 1, two = 2, three = 3); ~ John Williams
RE: Passing arguments
On 20 Sep 2002, Aaron Sherman wrote: : I assumed that's what C//=$_ was. It does have the disadvantage of : looking like variable assignment, though. BTW, latest leaning is toward = rather than //= for parameter defaults, since it can, in fact, be undef if the parameter is supplied, while //= seems to imply otherwise. And //= is too visually disruptive to the signature. Larry
Re: hotplug regexes, other misc regex questions
On Fri, 20 Sep 2002, Sean O'Rourke wrote: : On Fri, 20 Sep 2002, Larry Wall wrote: : But if a fast implementation needs to keep pointers into a string : rather than offsets from the beginning, we're asking for core dumps if : the string is modified out from under the pointers, or we have to : adjust all known pointers any time the string may be modified. : : With the current Parrot GC, keeping pointers into the string while doing : unrelated allocation will get you a core dump, since the string body might : be copied. So unless the regex engine copies strings off into its own : private non-collected storage, we're stuck with offsets anyways. That's fine, if it's a constraint. I had thought perhaps COW would allow a locked-down copy to work with without forcing unnecessary copying, but I suppose it doesn't hook into GC at that level. I'd also hoped it would solve any $-style inefficiencies. But hey, that's not my job this time around... :-) Larry
RE: Passing arguments
On Fri, 20 Sep 2002, Larry Wall wrote:
The current thinking as of Zurich is that the given passes in
separate from the ordinary parameters:
sub ($a,$b,$c) is given($x) {...}
That binds the dynamically surrounding $_ to $x as an out-of-band
parameter. Can also bind to $_ to make it the current topic.
Does this mean that we allow/encourage uses of $_ other than as a default
for an optional argument? I think it would be less confusing and
error-prone to associate the underscore-aliasing with the parameter $_
will be replacing, i.e. this
sub foo($a, $b = given) { ... }
vs this
sub foo($a; $b) is given($b) { ... }
or this
sub foo($a; $b) is given($c) {
$b //= $c;
...
}
Furthermore, if the caller can pass undef for the second parameter, I
don't see a way to distinguish in the third variant between a legitimately
passed undef, for which we don't want $_, and a missing optional argument,
for which we do.
/s
Re: Passing arguments
Larry said: BTW, latest leaning is toward = rather than //= for parameter defaults, ... Horray! Sorry. Couldn't resist. :-) -angel Simple men are happy with simple presents
Re: Regex query
On Fri, 20 Sep 2002, John Williams wrote:
: On Fri, 20 Sep 2002, Larry Wall wrote:
:
: Yes, in fact any list forced into scalar context will make a ref in Perl 6:
:
: $arrayref = (1,2,3);
:
: That would seem to obviate the need for brackets to define array
: references. Is there any case where [1,2,3] would be needed instead of
: (1,2,3)?
Sure, in a list context. [1,2,3] is really short for scalar(1,2,3).
: Also, does any list include a list of pairs? Because that would look
: more like a hash than a list.
:
: $ref = ( one = 1, two = 2, three = 3);
Sure. If you really want a hash, use {...}. (Extra rules apply
for parameter lists, though.)
Larry
RE: Passing arguments
On Fri, 20 Sep 2002, Sean O'Rourke wrote:
: On Fri, 20 Sep 2002, Larry Wall wrote:
: The current thinking as of Zurich is that the given passes in
: separate from the ordinary parameters:
:
: sub ($a,$b,$c) is given($x) {...}
:
: That binds the dynamically surrounding $_ to $x as an out-of-band
: parameter. Can also bind to $_ to make it the current topic.
:
: Does this mean that we allow/encourage uses of $_ other than as a default
: for an optional argument? I think it would be less confusing and
: error-prone to associate the underscore-aliasing with the parameter $_
: will be replacing, i.e. this
:
: sub foo($a, $b = given) { ... }
:
: vs this
:
: sub foo($a; $b) is given($b) { ... }
:
: or this
:
: sub foo($a; $b) is given($c) {
: $b //= $c;
: ...
: }
We want to be able to write CORE::print, among other things.
: Furthermore, if the caller can pass undef for the second parameter, I
: don't see a way to distinguish in the third variant between a legitimately
: passed undef, for which we don't want $_, and a missing optional argument,
: for which we do.
You can check for that with exists.
We felt you could use exists to check a parameter for having been passed.
BTW, I may be out of touch for a week. Don't know if I'll have
Internet access where I'll be. YAPC::Europe is just going through
the final announcements as I type, so my current connection will go
away soon.
Larry
Re: Regex query
On Fri, 20 Sep 2002, Larry Wall wrote: On Fri, 20 Sep 2002, John Williams wrote: : On Fri, 20 Sep 2002, Larry Wall wrote: : : Yes, in fact any list forced into scalar context will make a ref in Perl 6: : : $arrayref = (1,2,3); : : That would seem to obviate the need for brackets to define array : references. Is there any case where [1,2,3] would be needed instead of : (1,2,3)? Sure, in a list context. [1,2,3] is really short for scalar(1,2,3). I was just thinking that $((1,2,3)) is also the same as [1,2,3], and shorter than scalar(1,2,3). ~ John Williams
Re: Passing arguments
Personally, I like the looks of
sub foo($a, $b is given) { ... }
Does this mean that we allow/encourage uses of $_ other than as a default
for an optional argument? I think it would be less confusing and
error-prone to associate the underscore-aliasing with the parameter $_
will be replacing, i.e. this
sub foo($a, $b = given) { ... }
vs this
sub foo($a; $b) is given($b) { ... }
or this
sub foo($a; $b) is given($c) {
$b //= $c;
...
}
Furthermore, if the caller can pass undef for the second parameter, I
don't see a way to distinguish in the third variant between a legitimately
passed undef, for which we don't want $_, and a missing optional argument,
for which we do.
/s
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
It's times like these that I wish I was a leper --Bob.
Re: Regex query
John Williams wrote: On Fri, 20 Sep 2002, Larry Wall wrote: On Fri, 20 Sep 2002, John Williams wrote: : On Fri, 20 Sep 2002, Larry Wall wrote: : : Yes, in fact any list forced into scalar context will make a ref in Perl 6: : : $arrayref = (1,2,3); : : That would seem to obviate the need for brackets to define array : references. Is there any case where [1,2,3] would be needed instead of : (1,2,3)? Sure, in a list context. [1,2,3] is really short for scalar(1,2,3). I was just thinking that $((1,2,3)) is also the same as [1,2,3], and shorter than scalar(1,2,3). I wonder if you can't just use $(1, 2, 3) to the same effect. Also, I wonder if you can do this: my LoL = ( (1a, 2a), (1b, 2b), (1c, 2c) ); If you can, the only case where I could see [1, 2, 3] being necessary is in a sub call where the parameters are wrapped in parentheses. md |- matt diephouse
Re: Regex query
I was just thinking that $((1,2,3)) is also the same as [1,2,3],
and shorter than scalar(1,2,3).
I wonder if you can't just use $(1, 2, 3) to the same effect.
I think you can. I was under the impression that the C comma was dying,
so that would have to make a list or err.
Also, I
wonder if you can do this:
my LoL = ( (1a, 2a),
(1b, 2b),
(1c, 2c) );
Yeah, I think to get Perl5 behavioueaur :), you do this:
my flatL = ( *(1a, 2a), *(1b, 2b) );
Does this do the same thing?
my flatL = *( (1a, 2a), (1b, 2b) );
(Heh, I just got a fun thought:)
my $traversal_time = 2***@list;
If you can, the only case where I could see [1, 2, 3] being necessary is
in a sub call where the parameters are wrapped in parentheses.
Not even then, if $(1, 2, 3) is allowed. If so, it might be possible to
find another use for [...]. I like that syntax, but if we need a
balanced delimiter to do something else, that could be it...
Of course, the parallel [...] to foo[...] goes nicely with
{...} to %foo{...}, so it will probably stay.
Luke
possible bugs in Exegesis 5 code for matching patterns
Here is a discussion thread of Exegesis 5
http://www.perl.com/pub/a/2002/08/22/exegesis5.html at
http://developers.slashdot.org/developers/02/08/23/1232230.shtml?tid=145
But the signal/noise is too low, with side tracks into
Monty Python etc.
In section Smarter alternatives there is this code:
{ @$appendline =~ s/in_marker//;
I think this needs a backslash in front of the symbol,
and a space after in_marker, i.e. it should be:
{ @$appendline =~ s/in_marker/\sp/;
That a small issue. But the following is more
important because it strikes at the ease of
using inheritance of grammars (i.e. patterns).
In
http://www.perl.com/pub/a/2002/08/22/exegesis5.html?page=5#different_diffs
we see the code:
rule fileinfo {
out_marker3 $oldfile:=(\S+) $olddate:=[\h* (\N+?) \h*?] \n
in_marker3 $newfile:=(\S+) $newdate:=[\h* (\N+?) \h*?] \n
}
rule out_marker { \+ sp }
rule in_marker { - sp }
The sp means a single literal space.
So I think out_marker3 means look for + + +
rather than +++ which is what is really needed
to match a Unified diff. Similarly for in_marker3
Or am I missing something?
If these are bugs, then what would be the best way to
fix the code while retaining as much reuse as possible.
Hopefully helpfully yours,
Steve
--
Steven Tolkin [EMAIL PROTECTED] 617-563-0516
Fidelity Investments 82 Devonshire St. V8D Boston MA 02109
There is nothing so practical as a good theory. Comments are by me,
not Fidelity Investments, its subsidiaries or affiliates.
Re: Regex query
According to Luke Palmer: I think to get Perl5 behavioueaur :), you do this: my @flatL = ( *(1a, 2a), *(1b, 2b) ); Geez, I hope not, because that would imply that in my @v = ( func() ); that func is called in a scalar context. -- Chip Salzenberg - a.k.a. -[EMAIL PROTECTED] It furthers one to have somewhere to go.
RE: Regex query
Larry wrote: : $shouldbe3 = (1,2,3) + 0; It's 3, though not for the reason a Perl 5 programmer would think. (In Perl 6 it's the length of the anonymous array, not the last value.) This kind of clever magic always makes me nervous: it introduces subtle bug potentials. (7,8,9) == 3 # true (7,8) == 2 # true (7) == 1 # false () == 0 # true? As someone who regularly writes code generators -- and even as someone who occasionally edits code without thinking straight, I am certain that I will, on occasion, introduce bugs through this mechanism. If the [] list-ref composers are to remain, there seems no good reason to add a redundant behaviour to parentheses. Or am I missing something? Dave.
Re: Regex query
According to David Whipp: (7,8,9) == 3 # true (7,8) == 2 # true (7) == 1 # false () == 0 # true? Hell, yes, why didn't I think of that? This is exactly the same problem that afflicts Python's tuple syntax! Larry, I strongly suggest that making () act in any way like [] is a VERY BAD IDEA. -- Chip Salzenberg - a.k.a. -[EMAIL PROTECTED] It furthers one to have somewhere to go.
Re: Regex query
On Fri, 20 Sep 2002, Chip Salzenberg wrote: According to Luke Palmer: I think to get Perl5 behavioueaur :), you do this: my flatL = ( *(1a, 2a), *(1b, 2b) ); Geez, I hope not, because that would imply that in my v = ( func() ); that func is called in a scalar context. What? No it wouldn't. I was talking about Perl5 behavioueaur in the exampeaule. In that *(blah blah) flattens lists, not provides scalar context or whatever you were saying. my v = $( func() ); Would provide scalar context. But then assign it to a list... Luke
RE: Regex query
On Fri, 20 Sep 2002, David Whipp wrote: Larry wrote: : $shouldbe3 = (1,2,3) + 0; It's 3, though not for the reason a Perl 5 programmer would think. (In Perl 6 it's the length of the anonymous array, not the last value.) This kind of clever magic always makes me nervous: it introduces subtle bug potentials. (7,8,9) == 3 # true (7,8) == 2 # true (7) == 1 # false () == 0 # true? I believe the last two cases should be: (7,)== 1 (,) == 0 Because its the perl6 comma that creates the list, not the parenthesis. ~ John Williams
Re: Regex query
This kind of clever magic always makes me nervous: it introduces subtle bug potentials. (7,8,9) == 3 # true (7,8) == 2 # true (7) == 1 # false () == 0 # true? I believe the last two cases should be: (7,)== 1 (,) == 0 Because its the perl6 comma that creates the list, not the parenthesis. ~ John Williams If this is the case, then can you also have: (,7) What is its length? Tanton
Re: Regex query
According to John Williams: I believe the last two cases should be: (7,)== 1 (,) == 0 Gack! It's Python's tuple syntax! Run away! Run away! Seriously, having actually programmed Python for money (no smiley -- it was NOT fun), I can say that this syntactical hack would be a horrible choice for borrowing from Python. Heck, I'd rather Perl take Python's import than this abomination of punctuation. -- Chip Salzenberg - a.k.a. -[EMAIL PROTECTED] It furthers one to have somewhere to go.
Re: Regex query
On Fri, Sep 20, 2002 at 09:02:52PM -0600, John Williams wrote: On Fri, 20 Sep 2002, Tanton Gibbs wrote: If this is the case, then can you also have: (,7) What is its length? Hmm, it's a syntax error in perl5. I'd advocate it continuing to be a syntax error in perl 6. Maybe () is still the empty list in perl6, since it's not ambiguously something else. Sounds good to me.. But I cannot tell whether (7) is list context or numeric context, Nope, you can't tell without the surrounding context: (7) + 0;# numeric $a = (7); # list (7) == 1; # boolean (same as (7).length == 1) so it seems like the listifying comma is needed to disambiguate, especially if it's next to a numeric comparison operator. I don't think so. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Regex query
On Fri, Sep 20, 2002 at 02:17:42PM -0700, David Whipp wrote: Larry wrote: : $shouldbe3 = (1,2,3) + 0; It's 3, though not for the reason a Perl 5 programmer would think. (In Perl 6 it's the length of the anonymous array, not the last value.) This kind of clever magic always makes me nervous: it introduces subtle bug potentials. (7,8,9) == 3 # true (7,8) == 2 # true (7) == 1 # false Why is this one false? I'd expect it to be true just as the others. () == 0 # true? Same here. . If the [] list-ref composers are to remain, there seems no good reason to add a redundant behaviour to parentheses. Or am I missing something? I tend to agree with you here though. We could both be missing something :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Regex query
This kind of clever magic always makes me nervous: it introduces subtle bug potentials. (7,8,9) == 3 # true (7,8) == 2 # true (7) == 1 # false Why is this one false? I'd expect it to be true just as the others. (7) == 7 why? Otherwise, we couldn't use parens for mathematical expressions (3 + 4) == 7 -- the mathematical way (3 + 4) == 1 -- the length of the list ... BAD! Tanton
Re: Regex query
On Fri, 20 Sep 2002, Jonathan Scott Duff wrote: But I cannot tell whether (7) is list context or numeric context, Nope, you can't tell without the surrounding context: (7) + 0;# numeric $a = (7); # list (7) == 1; # boolean (same as (7).length == 1) No, that last one is clearly numeric context. == operates on numbers and returns boolean. I can't tell whether (7).length is asking for the length of 7 or the length of a list, but I would be badly surprised if (3+4).pow(2) returned 1 instead of 49. ~ John Williams
