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 { *
SC>* "raiddev" +
are the quotes there literals? they aren't in the file format i think.
SC> ( | | )+ };
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 () 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 C 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 C 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 C 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///\ $oldfile:=(\S+) $olddate:=[\h* (\N+?) \h*?] \n
<3> $newfile:=(\S+) $newdate:=[\h* (\N+?) \h*?] \n
}
rule out_marker { \+ }
rule in_marker { - }
The means a single literal space.
So I think <3> means look for "+ + + "
rather than "+++" which is what is really needed
to match a Unified diff. Similarly for <3>
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, 20 Sep 2002, Tanton Gibbs wrote: > > 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? Hmm, it's a syntax error in perl5. Maybe () is still the empty list in perl6, since it's not ambiguously something else. But I cannot tell whether (7) is list context or numeric context, so it seems like the listifying comma is needed to disambiguate, especially if it's next to a numeric comparison operator. ~ John Williams
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
On Fri, Sep 20, 2002 at 10:16:38PM -0400, Chip Salzenberg wrote: > 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. I would be surprised if the entire Perl community didn't unanimously agree with you. I know this is one of the pythonisms that bugs me the most. -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
