-bits.pod
Log Message:
---
Mention unspace disallowed in regex (except \#)
The current engine disallows unspace in regexex as too ambiguous.
This is fine for actual whitespace, but is counterintuitive when people
try to backslash the # character. So \# is now specifically allowed
to match
-bits.pod
Log Message:
---
Mention unspace disallowed in regex (except \#)
The current engine disallows unspace in regexex as too ambiguous.
This is fine for actual whitespace, but is counterintuitive when people
try to backslash the # character. So \# is now specifically allowed
to
-library/Exception.pod
Log Message:
---
[S32::Exception] Add X::Regex::SolitaryQuantifier
-regex.pod
Log Message:
---
remove autodeclaration fossil from regex
Message:
---
Regex vars declarative iff declared constant
Making the LTM engine track whether a variable has changed is
not friendly to most VMs. The spec was engaged in P5-Think of the
there's-only-one-implementation-so-we-can-get-fancy kind. sorear++
On Tue, Aug 10, 2010 at 9:00 PM, wrote:
> Once the & operator is in rakudo, though... I gather I /could/ do something
> like the following
>
> ^ [ * & ] $
>
> And this would in effect ensued that the sequence "abc" doesn't exist
> anywhere across the match for
>
>
> Is this correct?
>
Not
Back to your original advice...
> If you want to match an alphabetic string which does not include 'abc'
> anywhere, you can write this as
>
> ^ [ ]* $
I presume this only works here because is one character... if instead
of I used anything more complicated
(for example)
token name
{
philippe.beauch...@bell.ca wrote:
> On the & operator... are you saying that it would operate basically as
> expected...
> allowing sets of rules and'ed rather than or's with the | ?
Yes, with the limitation that both parts separated by & have to match
the same length of string, so that for exam
he | ?
--- Phil
-Original Message-
From: Moritz Lenz [mailto:mor...@faui2k3.org]
Sent: August 10, 2010 2:09 PM
To: Beauchamp, Philippe (6009210)
Cc: perl6-language@perl.org
Subject: Re: regex and
Hi,
philippe.beauch...@bell.c
ote that is a zero-width assertion, so your example regex
matches at the start of a string, if it does not begin with 'abc'.
Since you anchor it to the end of string too, it can only ever match the
empty string.
You can achieve the same with just ^$.
If you want to match an alphabetic
Hi there...
New to the list and getting to understand perl6 after a bit of a hiatis from
the Perl world.
I'm working my way through the new grammar syntax trying to implement some
useful modules, and was wondering if there is a mechanism within the grammar
constructs to allow two rules to appl
Author: lwall
Date: 2010-06-05 21:02:35 +0200 (Sat, 05 Jun 2010)
New Revision: 31128
Modified:
docs/Perl6/Spec/S05-regex.pod
Log:
[S05] posit that cursor lists may be returned to a regex with <.gather { take
... }>
Modified: docs/Perl6/Spec/S05-reg
Use <{...}>. as the string returned is reinterpreted as a regex, if it consists
of the single quoted string then it's a literal, but you must include the
single quotes in the result returned. E.g.,
<{ my $x = funct($a, $b, $c); "'$x'";}>
Mark
Is there not a way to run arbitrary code and interpolate the result as
a literal string (instead of a Regex)?
I assume that {...} is intended to be where you hook in
semantics/actions mid-parse, but it seems a bit counter-intuitive that
the same syntax interpolates in double-quote context but
On Sun, Jan 3, 2010 at 8:30 PM, Moritz Lenz wrote:
>
> But since $input can contain closures, arbitrary code can be executed.
> I'd like to propose a way to compile a string to a regex which doesn't
> allow code execution.
>
So would I.
I would also like it to be the
Some Perl 5 programs take a regex (in string form) as input, and simply
interpolate it into a regex.
In Perl 6, you'd do that as
my $re = rx/ <$input> /;
But since $input can contain closures, arbitrary code can be executed.
I'd like to propose a way to compile a string to a reg
IMHO some details of Unicode property support seem unspecified:
1) Assumption: *ALL* Unicode properties and all of their aliases should
be supported.
E.g. this will also include the derived properties 'Grapheme_Base' and
'Grapheme_Extent' (missing in Perl 5 - obviously a bug in 'unicore').
en there, the language inside the parens is still
inherited from the surrounding language braid, which is a lexically
scoped concept. The current outermost language is called $~MAIN (see
S02) while the current regex language is called $~Regex. It just
has to look outward a bit further to see what
On Sat, Aug 08, 2009 at 05:45:40PM -0400, Austin Hastings wrote:
> [...]
> Specifically, is
> token { ... }
> going to match the same pattern as
> rule { ... }
> ??
>
> I ask because (I just did it, and) with rules encouraging the liberal
> use of whitespace, and implicitly generating <
S05 mentions the magic pattern in two locations, but I cannot
find a specification of the interaction between and the
ratcheting {rule/token} status.
Specifically, is
token {
...
}
going to match the same pattern as
rule {
...
}
??
I ask because (I just did it, and) with rules enco
On Thu, Dec 04, 2008 at 07:00:55PM +0100, Moritz Lenz wrote:
> GW wrote:
> > I found something that could be problematic (haven't yet found out if it
> > should be a special case) in Synopsis 5. More precisely it is under the
> > chapter "Accessing captured subrule
On Wed, Dec 3, 2008 at 6:19 PM, GW <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I found something that could be problematic (haven't yet found out if it
> should be a special case) in Synopsis 5. More precisely it is under the
> chapter "Accessing captured subru
Hello,
GW wrote:
> I found something that could be problematic (haven't yet found out if it
> should be a special case) in Synopsis 5. More precisely it is under the
> chapter "Accessing captured subrules" in the test case
> t/regex/from_perl6_rules/capture.
Hi,
I found something that could be problematic (haven't yet found out if it
should be a special case) in Synopsis 5. More precisely it is under the
chapter "Accessing captured subrules" in the test case
t/regex/from_perl6_rules/capture.t lines 67–71:
ok(eval(
On Sat, Sep 06, 2008 at 09:41:07AM -0700, Larry Wall wrote:
> On Sat, Sep 06, 2008 at 11:44:05AM +0200, Moritz Lenz wrote:
> : The subject says it all: should !~~ with a regex on the RHS set $/?
>
> For now I would assume that the meta operator rewrites
>
> $a !~~ $b
>
On Sat, Sep 06, 2008 at 11:44:05AM +0200, Moritz Lenz wrote:
: The subject says it all: should !~~ with a regex on the RHS set $/?
For now I would assume that the meta operator rewrites
$a !~~ $b
to
(not $a ~~ $b)
so .ACCEPTS has no clue that it is dealing with a negated operator.
In
The subject says it all: should !~~ with a regex on the RHS set $/?
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
On Sun, Aug 31, 2008 at 08:33:48AM -0600, Stephen Simmons wrote:
> In S05, I found this regarding the generalized repetition specifier:
>
> ** '|'# repetition controlled by presence of character
>
> I tried it out with
>
> rule thislist { ** '|' };
>
> and got (with Rakudo):
>
>
Patrick R. Michaud wrote:
> On Thu, Aug 28, 2008 at 08:32:41AM -0700, Carl Mäsak wrote:
>> r30590:
>> $ ./perl6 -e 'regex a { b }; "b" ~~ a'
>> too few arguments passed (0) - 2 params expected
>> [...]
>>
>> I've also added tes
Stephen Simmons wrote:
> In S05, I found this regarding the generalized repetition specifier:
>
> ** '|'# repetition controlled by presence of character
>
> I tried it out with
>
> rule thislist { ** '|' };
>
> and got (with Rakudo):
>
> perl6regex parse error: Error in closure q
In S05, I found this regarding the generalized repetition specifier:
** '|'# repetition controlled by presence of character
I tried it out with
rule thislist { ** '|' };
and got (with Rakudo):
perl6regex parse error: Error in closure quantifier at offset 28, found '''
Is this fe
Sáb, 2008-06-07 às 16:01 +0200, Stéphane Payrard escreveu:
> what is the equivalent convention for yadayadayada in regex. Cuz ...
> is alread meaningful in regex. Should I use <...> or {...} ?
> Should the first be predefined?
If I understand correctly, {...} should already be p
what is the equivalent convention for yadayadayada in regex. Cuz ...
is alread meaningful in regex. Should I use <...> or {...} ?
Should the first be predefined?
I want something that is a placeholder that parses but fails if
someone pastes it. In other words the equivalent of
a sub yad
Moritz Lenz wrote:
> I noticed that in larger grammars (like STD.pm and many PGE grammars in
> the parrot repo) string literals are always quoted for clarity
>
> regex foo {
> 'literal'
> }
>
> Since I think this is a good idea, we could just as
I have two questions/suggestions regarding regex syntax:
1)
The :ii modifier is influenced by :sigspace modifier.
IMHO this is ugly, because the matching part and the replacement part of a
regex should be as orthogonal as possible.
Therefore I'd like a different syntax for :ii :sigspace,
On Tue, Jan 16, 2007 at 02:05:44PM -0600, Patrick R. Michaud wrote:
: On Tue, Jan 16, 2007 at 10:41:03AM -0800, Larry Wall wrote:
: > Note, in case you don't read synopsis checkins: the previous checkin
: > majorly changes the semantics of | within regex to support required
: >
On Tue, Jan 16, 2007 at 10:41:03AM -0800, Larry Wall wrote:
> Note, in case you don't read synopsis checkins: the previous checkin
> majorly changes the semantics of | within regex to support required
> longest-token matching semantics rather than left-to-right matching.
> This
Note, in case you don't read synopsis checkins: the previous checkin
majorly changes the semantics of | within regex to support required
longest-token matching semantics rather than left-to-right matching.
This is nearly on the same philosophical level as requiring the
tail-recursion optimiz
Larry Wall wrote:
On Sat, Oct 07, 2006 at 03:28:04PM -0700, Jonathan Lang wrote:
: It's been indicated that several regex modifiers that are found in
: Perl5 are gone. That's all well and good, unless you're using the
: Perl5 modifier to port code to perl6. What happens if you
On Sat, Oct 07, 2006 at 03:28:04PM -0700, Jonathan Lang wrote:
: It's been indicated that several regex modifiers that are found in
: Perl5 are gone. That's all well and good, unless you're using the
: Perl5 modifier to port code to perl6. What happens if you're trying
: to
It's been indicated that several regex modifiers that are found in
Perl5 are gone. That's all well and good, unless you're using the
Perl5 modifier to port code to perl6. What happens if you're trying
to port in a regex that made use of one of the now-obsolete modifiers?
Bea
Patrick R. Michaud wrote:
Jerry is correct that S05 is the place to look for information
on this. But to summarize an answer to your question:
Thank you very much for the swift and thorough answer. It answered all
my questions. Your reply was very pedagogical and deserves to go into
the man
>the grammars in Parrot 0.4.4 for punie and APL use rule, token and regex
> >elements.
> >
> >Can someone please clarify the difference between these three types, and
> >when you should use one or the other?
>
> i'm forwarding this to p6l, as it's a lang
On 6/2/06, Rene Hangstrup Møller <[EMAIL PROTECTED]> wrote:
Hi
I am toying around with Parrot and the compiler tools. The documenation
of Perl 6 grammars that I have been able to find only describe rule. But
the grammars in Parrot 0.4.4 for punie and APL use rule, token and regex
elements
On Tue, Feb 14, 2006 at 11:35:18AM -0800, David Romano wrote:
> On 2/14/06, Luke Palmer <[EMAIL PROTECTED]> wrote:
> > On 2/14/06, David Romano <[EMAIL PROTECTED]> wrote:
> > > I don't want to just skip tags wholly, because they do
> > > serve a purpose, but only in a particular context. (Can
>
thought about the closure at the end.
> > If that adverb were available, then I could have a rule that doesn't include
> > two other rules:
> > line:without(&&) {
> > ^^ [.*] $$
> > }
> >
> >
> > The rule above would match a
uding your test at the end:
rule text_no_date {
(.*)
{ $1 !~ // }
}
Or if you just don't want one at the beginning:
rule text_no_date {
> .*
}
>
> If that adverb were available, then I could have a rule that doesn't include
> two other rule
Hello everyone,
This is my first post to the actual mailing list and not to Google Groups
(yeah, took me a bit to figure out they're not the same). I have a few
questions about the rules in Perl 6, and hopefully I'm not repeating stuff
that's already been brought up before. (I searched through the
Brad Bowman skribis 2005-12-09 20:14 (+0100):
> $str ~~ my m/ mv @files:=+ $dir:= /
> Nah, that's ugly.
It's mostly ugly because you're not used to it, I think.
my m[mv @files:=+ $dir:=] ~~ $str;
Looks nicer, though.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convoluti
On 08/12/05 17:12, Larry Wall wrote:
> On Thu, Dec 08, 2005 at 11:14:16PM +0100, Brad Bowman wrote:
> : it may be acceptable with a "my" in the regex or limiting the
> : additions to declaring scope.
>
> I've gone around about that in my head lots of time, but there
On Thu, Dec 08, 2005 at 11:14:16PM +0100, Brad Bowman wrote:
: Hello,
:
: I'd like to get clarification on the scoping of variables
: bound in a regex. It's described in S05 as follows:
:
: External aliasing
:
: * Instead of using internal aliases like:
:
:
Hello,
I'd like to get clarification on the scoping of variables
bound in a regex. It's described in S05 as follows:
External aliasing
* Instead of using internal aliases like:
m/ mv @:=+ $:= /
the name of an ordinary variable can be used as an "exter
> Phil, please see the perlfunc entry for "pos" and the perlre section
> on \G. This is what you need.
Thanks a lot! I know about pos but thought it was read-only.
And \G is relatively new, isn't it? Certainly wasn't
existing in '97 when I learned perl :-)
And the "basics" are seldom read again
> From: "Ph. Marek" <[EMAIL PROTECTED]>
> Date: Wed, 12 Feb 2003 08:42:57 +0100
>
> --Boundary-00=_BsfS+fOE40iabfr
> Content-Type: text/plain;
> charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> Hello everybody,
>
> I've sometimes the task to analyse a stri
Hello everybody,
I've sometimes the task to analyse a string
starting from a given position, where this position
changes after each iteration. (like index() does)
As this is perl there are MTOWTDIIP but I'd like
to know the fastest.
So I used Benchmark.pm to find that out. (script attached)
David Whipp wrote:
> $b = 7, 6, 5
> @b = 7, 6, 5
I understand that C's *interpretation* of the comma operator will be expunged from
Perl 6. But unless comma's *precedence* is also changing, neither of those statements
would build a list with three elements.
It seems to me that
$b = 7, 6,
Luke Palmer wrote:
> On 21 Sep 2002, Smylers wrote:
>
> > But because C<$num> _might_ be used as an array ref, the data has to
> > be kept around, which is wasteful.
>
> The programmer should know whether it would or wouldn't,
Oh, I wasn't doubting that. I was just concerned that if the 'typi
Aaron Sherman wrote:
> On Sat, 2002-09-21 at 06:38, Smylers wrote:
>
> > ... lists now use square brackets.
>
> I don't disagree that this is a good thing, but let's look at some
> cases that might not look the way you had intended:
Oh, I hadn't really intending anything. Starting from what
On Mon, Sep 23, 2002 at 11:54:06PM -0600, John Williams wrote:
> After testing various cases of x, I came up with one that I cannot
> explain. Can someone tell me what is happening here (in perl5)?
>
> $ perl -le 'print "@{[ $a = ('a','b') x 3 ]}"; print $a'
> a bbb
> bbb
>
> or in other words
On Tue, 2002-09-24 at 17:27, John Williams wrote:
> If I understand our non-conclusions so far, we're waiting for Larry to
> clarify:
>
> 1) how to create a 1-tuple/1-item list?
>
> 2) how to interpret the flattened list context? e.g. given this:
>
> > $x = (1,2,3);
> > @y = (
On Tue, 24 Sep 2002, Mike Lambert wrote:
> >
> > $a = (1, 2, 3); # Same as Perl 5's $a = [1,2,3];
>
> $a = (1) should then do $a = [1], according to the above.
>
> This implies that:
>
> ($a) = (1) implies that $a is [1], something I don't particularly agree
> with.
You may be missing the chang
> From: Jonathan Scott Duff
> > $b = 7, 6, 5
> > @b = 7, 6, 5
> >
> > Again, both create identical objects, under different
> > interfaces. But now we have a problem with +$b: what should
> > this mean? To be consistant with +$a (above), I would
> > suggest that it simply returns the sum of
In a message dated Tue, 24 Sep 2002, Mike Lambert writes:
> Consider:
> $a = (1);
> and
> ($a) = (1);
Yes? They both do the same thing--set $a to 1. It looks like the bottom
one is a list assigned to a list, but that might be optimized out, as it
doesn't matter.
> > 5. Assignment to arrays an
> 2. Scalar assignment.
>
> my $a;# 1.
> $a = X;
>
> my $a;# 3.
> ($a) = X;
>
> These should all do the same thing, regardless of X.
Consider:
$a = (1);
and
($a) = (1);
> 5. Assignment to arrays and lists.
>
> $a = (1, 2, 3); # Same as Perl 5's $a = [1,2,3];
On Tue, 2002-09-24 at 14:47, David Whipp wrote:
> It seems that the fundamental problem is the dichotomy between
> a scalar, and a list of 1 elem. Thus, we want
After the first couple of messages, that was really no longer *my*
concern, but I can't speak for others. My concern was mostly that
par
On Tue, Sep 24, 2002 at 11:47:16AM -0700, David Whipp wrote:
> It seems that the fundamental problem is the dichotomy between
> a scalar, and a list of 1 elem. Thus, we want
>
> $a = 7
>
> to DWIM, whether I mean a list, or a scalar. Seems to me that
> the best way to solve a dichotomy is to d
It seems that the fundamental problem is the dichotomy between
a scalar, and a list of 1 elem. Thus, we want
$a = 7
to DWIM, whether I mean a list, or a scalar. Seems to me that
the best way to solve a dichotomy is to declare it to not to
be one: a scalar *IS* a list of one element. The only t
> > In a message dated Tue, 24 Sep 2002, Chip Salzenberg writes:
>
> > > then what about
> > >
> > >$a = (1)
> > >
> > > ? And if someone says that I have to write:
> > >
> > >$a = (1,)
> > >
> > > then I am going on the warpath. That Way Lay Python.
You _can_ write that, but you don't
On Tue, Sep 24, 2002 at 12:14:10PM -0400, Trey Harris wrote:
> In a message dated Tue, 24 Sep 2002, Jonathan Scott Duff writes:
>
> > On Tue, Sep 24, 2002 at 11:14:04AM -0400, Aaron Sherman wrote:
> > > Again, we're wading into the waters of over-simplification. Let's try:
> > >
> > > sub
In a message dated Tue, 24 Sep 2002, Jonathan Scott Duff writes:
> On Tue, Sep 24, 2002 at 11:14:04AM -0400, Aaron Sherman wrote:
> > Again, we're wading into the waters of over-simplification. Let's try:
> >
> > sub foo1(){ my @foo=(1,2,3); return @foo; }
> > sub foo2(){ my $foo
On Tue, Sep 24, 2002 at 11:14:04AM -0400, Aaron Sherman wrote:
> Again, we're wading into the waters of over-simplification. Let's try:
>
> sub foo1(){ my @foo=(1,2,3); return @foo; }
> sub foo2(){ my $foo = [1,2,3]; return $foo; }
> sub foo3(*@list) { print @list.length,
In a message dated 24 Sep 2002, Aaron Sherman writes:
> That doesn't really work. Because now you introduce the case where:
>
> $x = (1,2,3);
> @y = (1,2,3);
> $z = [1,2,3];
> push @a, $x, @y, $z, (1,2,3), [1,2,3];
>
> Behaves in ways that will take hours to explain to newb
On Tue, 2002-09-24 at 11:07, Trey Harris wrote:
> In a message dated Tue, 24 Sep 2002, Chip Salzenberg writes:
> > then what about
> >
> >$a = (1)
> >
> > ? And if someone says that I have to write:
> >
> >$a = (1,)
> >
> > then I am going on the warpath. That Way Lay Python.
I would *
At 11:07 AM -0400 9/24/02, Trey Harris wrote:
>
>*shrug* Regardless of whether we like it, what Larry said is true unless
>and until he invokes Rule 2. And unless he invokes Rule 2,
>C is equivalent to C<[1,2,3]>.
Then perhaps, rather than fretting over the unpleasant consequences
of the curren
On Tue, 2002-09-24 at 10:27, Peter Haworth wrote:
> On 24 Sep 2002 05:21:37 -0400, Aaron Sherman wrote:
> > On Tue, 2002-09-24 at 01:46, Trey Harris wrote:
> > > sub push(@target is rw, *@list);
> >
> > Well, yes, but that wasn't the point. The C<*@list> will force array
> > flattening, thus
>
In a message dated Tue, 24 Sep 2002, Chip Salzenberg writes:
> According to Trey Harris:
> > According to Larry,
> > $a = (1,2,3);
> > is equivalent to
> > $a = [1,2,3];
> > because they're both equivalent to
> > $a = scalar(1,2,3)
>
> But that's the bit we're arguing about. If you allow
>
According to Trey Harris:
> According to Larry,
> $a = (1,2,3);
> is equivalent to
> $a = [1,2,3];
> because they're both equivalent to
> $a = scalar(1,2,3)
But that's the bit we're arguing about. If you allow
$a = (1,2)
then what about
$a = (1)
? And if someone says that I have
On 24 Sep 2002 05:21:37 -0400, Aaron Sherman wrote:
> On Tue, 2002-09-24 at 01:46, Trey Harris wrote:
> > sub push(@target is rw, *@list);
>
> Well, yes, but that wasn't the point. The C<*@list> will force array
> flattening, thus
>
> push @a, [1,2,3], 4;
>
> will (according to Larry's
On Tue, Sep 24, 2002 at 11:30:57AM +0100, Simon Cozens wrote:
> At any rate, I do wish we'd stop kidding ourselves that Perl 6 is at all
> going to be "cleaned up" or "regular"; I bet it'll end up with more edge
> cases and special exceptions than Perl 5.
Simon, Perl 6 *will* be more "regular" as
[EMAIL PROTECTED] (Aaron Sherman) writes:
> > If we have to resort to much magic to get these right, we're pretty much
> > doomed from the outset.
>
> You have that upside-down. Because this is so fundamental, it's worth a
> great deal of magic to make it "seem right" in as many contexts as
> pos
[EMAIL PROTECTED] (Aaron Sherman) writes:
> say that array refs behave the same as arrays in every way *except* as
> pertains to list flattening, and in that case, explicit flattening is
> required, otherwise the ref is kept in the flattened array.
Another blow to regularity. :(
--
buf[
On Tue, 2002-09-24 at 01:46, Trey Harris wrote:
> In a message dated 24 Sep 2002, Aaron Sherman writes:
> > This is because push is
> > almost certainly defined as:
> >
> > sub push(@target, *@list) { ... }
>
> That should be
>
> sub push(@target is rw, *@list);
Well, yes, but that wa
On Sun, 2002-09-22 at 08:07, Simon Cozens wrote:
> [EMAIL PROTECTED] (Jonathan Scott Duff) writes:
> > Why can't perl be smart enough to figure out what we mean?
>
> We're talking about lists, the second most fundamental data structure
> in the language.
>
> If we have to resort to much magic to
On Mon, 23 Sep 2002, Trey Harris wrote:
>
> So then, I think if there's just some clarification about how one-tuples
> are formed, I think everything I wrote in my earlier mail can DWIM
> correctly. There seems to be no magic here, quotations from LoTR to the
> contrary. :-)
Your post was very h
In a message dated 24 Sep 2002, Aaron Sherman writes:
> This is because push is
> almost certainly defined as:
>
> sub push(@target, *@list) { ... }
That should be
sub push(@target is rw, *@list);
but otherwise I think that's right.
Now, implementation in Perl 6 (though I assume it's
On Sat, 2002-09-21 at 06:18, Smylers wrote:
> $num = @massive;
>
> C<$num> becomes a reference to C<@massive>, but in a numeric context it
> will evaluate to the number of elements in that array.
>
But in most cases, you would never do this. You would do something like
my int $num =
In a message dated 24 Sep 2002, Aaron Sherman writes:
> Grrr... I want that to work, really I do, but since, as Larry has
> pointed out, there's no functional difference between an array ref and
> an array in Perl 6, they would be the same. This is because push is
> almost certainly defined as:
>
Replying to myself to clear a few things up...
In a message dated Mon, 23 Sep 2002, Trey Harris writes:
> 2. Scalar assignment.
>
> my $a;# 1.
> $a = X;
>
> my $a;# 2.
> $a = X;
>
> my $a;# 3.
> ($a) = X;
>
> my($a) = X; # 4.
>
> my($a)
On Mon, 2002-09-23 at 15:48, Luke Palmer wrote:
> On 23 Sep 2002, Simon Cozens wrote:
>
> > [EMAIL PROTECTED] (Luke Palmer) writes:
> > > Since we now have an explicit flattening operator (unary *), there's no
> > > need to differentiate between a "real" list and a reference to one.
> >
> > Wha
On Mon, 2002-09-23 at 16:58, Trey Harris wrote:
> 4. Numeric value.
>
> The progression spoken about at great length previously:
>
> +()# == 0
> +(0) # == WHAT? 0? 1?
> +(0,1) # == 2
> +(0,1,2) # == 3
> +(0,1,2,3) # == 4
> +(0,...,n) # == n + 1
>
>
In a message dated Mon, 23 Sep 2002, Luke Palmer writes:
> Y'all have it backwards.
>
> [1,*[2,[3,4,5]],6] # [1,2,[3,4,5],6]
> [1,*[2,*[3,4,5]],6] # [1,2,3,4,5,6]
>
> Flat flattens outwards, not inwards.
Ah. *slaps head* of course. That makes much more sense
On 24 Sep 2002, Simon Cozens wrote:
> [EMAIL PROTECTED] (Luke Palmer) writes:
> > push @a: [1,2,3,4];
> >
> > pushes an array ref onto @a.
> >
> > push @a: *[1,2,3,4];
> >
> > pushes 1, 2, 3, and 4 onto @a (as it would without the * and []).
>
> Remind me which language this is suppos
On Mon, 23 Sep 2002, Jonathan Scott Duff wrote:
> On Mon, Sep 23, 2002 at 04:58:55PM -0400, Trey Harris wrote:
> > for (1,("a","b","c"),3 { ... }
> >
> > and
> >
> > for 1,("a","b","c"),3 { ... }
> >
> > Now that I've ventured away from DWIMs and more into WIHDTEMs (What In
> > Hell Does T
On Mon, Sep 23, 2002 at 04:58:55PM -0400, Trey Harris wrote:
> for (1,("a","b","c"),3 { ... }
>
> and
>
> for 1,("a","b","c"),3 { ... }
>
> Now that I've ventured away from DWIMs and more into WIHDTEMs (What In
> Hell Does This Expression Mean), is the above equivalent to
>
> for 1,qw(a
[EMAIL PROTECTED] (Trey Harris) writes:
> May I suggest that we start with some DWIMmy examples
Sam sat on the ground and put his head in his hands. 'I wish I had
never come here, and I don't want to see no more magic,' he said, and
fell silent.
--
I hooked up my accelerator pedal in my car to
[EMAIL PROTECTED] (Luke Palmer) writes:
> push @a: [1,2,3,4];
>
> pushes an array ref onto @a.
>
> push @a: *[1,2,3,4];
>
> pushes 1, 2, 3, and 4 onto @a (as it would without the * and []).
Remind me which language this is supposed to be, again?
--
"Life sucks, but it's better th
I think this discussion has gotten out of hand, and I hope that Larry,
Damian or Allison will grace us with a resolution soon. :-)
May I suggest that we start with some DWIMmy examples and try to arrive at
a mechanism that will make them all DWIM? Here are my opinions, feel free
to shoot them do
On 23 Sep 2002, Simon Cozens wrote:
> [EMAIL PROTECTED] (Luke Palmer) writes:
> > Since we now have an explicit flattening operator (unary *), there's no
> > need to differentiate between a "real" list and a reference to one.
>
> What context does "push" impute on its operands?
>
> If
> p
On Sat, 2002-09-21 at 06:38, Smylers wrote:
> So if the difference between lists with parens and anon arrays with
> square brackets is going away, it may make sense to standardize on the
> latter rather than the former. In other words, lists now use square
> brackets.
>
> That frees up parens f
On Wed, Sep 18, 2002 at 05:01:35PM +0200, Damian Conway wrote:
> Steve Fink wrote:
> > print "yes" if "helo" =~ /hel { .pos-- } lo/;
>
> This definitely has to work. But remember the call to C is on
> the "match object" (i.e. $0), not the string.
>
> Actually, I would expect that *any* pattern
1 - 100 of 251 matches
Mail list logo
