:
M S02-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
:
M S02-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
:
M S32-setting-library/Exception.pod
Log Message:
---
[S32::Exception] Add X::Regex::SolitaryQuantifier
:
M S05-regex.pod
Log Message:
---
remove autodeclaration fossil from regex
-regex.pod
Log 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, philippe.beauch...@bell.ca wrote:
Once the operator is in rakudo, though... I gather I /could/ do something
like the following
^ [ !abc* name ] $
And this would in effect ensued that the sequence abc doesn't exist
anywhere across the match for name
-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.ca wrote:
rule TOP
{
^
[
alpha
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 example
Back to your original advice...
If you want to match an alphabetic string which does not include 'abc'
anywhere, you can write this as
^ [ !abc alpha ]* $
I presume this only works here because alpha is one character... if instead
of alpha I used anything more complicated
(for example)
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-regex.pod
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
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 Biggar
--
m...@biggar.org
mark.a.big...@comcast.net
mbig
On Sun, Jan 3, 2010 at 8:30 PM, Moritz Lenz mor...@faui2k3.org 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 default
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').
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 the current
S05 mentions the magic after pattern in two locations, but I cannot
find a specification of the interaction between after and the
ratcheting {rule/token} status.
Specifically, is
token {
... ?after x
}
going to match the same pattern as
rule {
... ?after x
}
??
I ask because (I just
On Sat, Aug 08, 2009 at 05:45:40PM -0400, Austin Hastings wrote:
[...]
Specifically, is
token { ... ?after x }
going to match the same pattern as
rule { ... ?after x }
??
I ask because (I just did it, and) with rules encouraging the liberal
use of whitespace, and implicitly
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 subrules in the test case
t/regex
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(' bookkeeper ~~ m/single ($/single
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.t lines 67–71:
ok(eval(' bookkeeper ~~ m
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 subrules in the test case
t/regex/from_perl6_rules
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 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
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
to
(not $a ~~ $b
On Sun, Aug 31, 2008 at 08:33:48AM -0600, Stephen Simmons wrote:
In S05, I found this regarding the generalized repetition specifier:
alt ** '|'# repetition controlled by presence of character
I tried it out with
rule thislist { alpha ** '|' };
and got (with Rakudo):
In S05, I found this regarding the generalized repetition specifier:
alt ** '|'# repetition controlled by presence of character
I tried it out with
rule thislist { alpha ** '|' };
and got (with Rakudo):
perl6regex parse error: Error in closure quantifier at offset 28, found '''
Stephen Simmons wrote:
In S05, I found this regarding the generalized repetition specifier:
alt ** '|'# repetition controlled by presence of character
I tried it out with
rule thislist { alpha ** '|' };
and got (with Rakudo):
perl6regex parse error: Error in closure
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 yada yada
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 parsed as a yada yada
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' subregex
}
Since I think this is a good idea, we could just as well enforce that, and
drop
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, maybe
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 optimization
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 is nearly on the same
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?
Bear in mind
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 port in a regex
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're trying
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.
Can
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 language question and probably
best asked there. that said, the regex/token/rule change
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
) {
^^ [.*] $$
}
The rule above would match a line with a date or name, but not a line
with
both.
Huh. That kind of test really wants a closure. You can't use the
regex because that requires that they match at the same place. You
can't use the logical , because date isn't an expression. Of
course
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 B tags wholly, because they do
serve a purpose, but only in a particular context. (Can ?ws
be
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
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 isn't
a good way to sneak a my
Brad Bowman skribis 2005-12-09 20:14 (+0100):
$str ~~ my m/ mv @files:=ident+ $dir:=ident /
Nah, that's ugly.
It's mostly ugly because you're not used to it, I think.
my m[mv @files:=ident+ $dir:=ident] ~~ $str;
Looks nicer, though.
Juerd
--
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 @files:=ident+ $dir:=ident /
the name of an ordinary variable can be used as an external
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:
:
: m/ mv @files:=ident
Juerd:
Ruud H.G. van Tol:
s/($search)/*\1*/go
\1 in Perl 5 is bad style and emits a warning
The point was to give \1 and \, in the replace part, a very limited
scope.
Maybe even better to limit \1 to the first '(?: ... )' in the search
part.
s/(?:$search)(?:.\1)+/\1/go
xy.xy.xy.xy --
On Mon, Sep 26, 2005 at 10:19:29PM +0200, Juerd wrote:
: In Perl 6, the match object $/ will instead be used. It's a bit harder
: to use with s///, because it will look ugly, but remember that you can
: always choose to use s^^^ or s[][] or any other of the many
: possibilities instead.
It's
Think about adding \ to the replacement part of a s///.
As in sed, the means the whole match.
Then one can do
s/$search/*\*/go
in stead of
s/($search)/*\1*/go
and there needs to be no $1 variable set up.
(I assume that using () always makes a $1 available, even if it is not
being
will no longer have anything to
do with regex matches.
and there needs to be no $1 variable set up.
Perl 6 will count from 0, so it'll be $0.
(I assume that using () always makes a $1 available, even if it is not
being used.)
Perl 5's $ is inefficient because of this. If the variable is used
anywhere
On Sep 26, 2005, at 4:19 PM, Juerd wrote:
Perl 5's $ is inefficient because of this. If the variable is used
anywhere, Perl will for every regex used capture everything.
My understanding is that this died with 5.10. Is that right?
--Dks
On Mon, Sep 26, 2005 at 05:00:00PM -0400, David Storrs wrote:
On Sep 26, 2005, at 4:19 PM, Juerd wrote:
Perl 5's $ is inefficient because of this. If the variable is used
anywhere, Perl will for every regex used capture everything.
My understanding is that this died with 5.10
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 in
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)
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 string
starting
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,
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: Snip
Oh, I hadn't really intending anything. Starting from what
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 'typical'
way
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 wasn't the
[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. :(
--
[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
possible.
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 long as
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 stated
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 to
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
$a = (1,2)
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
push
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,
Cscalar(1,2,3) is equivalent to C[1,2,3].
Then perhaps, rather than fretting over the unpleasant consequences
of
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 *never* suggest
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 newbies, and I
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 = [1,2,3];
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 foo1(){ my
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 _have_ to. [1], (1),
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
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 declare
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
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];
$a = (1)
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 and
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 its elements
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 change in the
On Sat, 21 Sep 2002 16:33:31 -0600 (MDT), Luke Palmer said:
You know, the idea that square brackets are the only things that can
make lists is starting to really appeal to me. Similar for squiggles
and hashes. I don't know how many times in my early Perl5 days I did
this:
Since we now
[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
push @a, [1,2,3,4];
and
push @a, 1,2,3,4;
are going to
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 for
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
push @a,
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
[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 than the
[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
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 This Expression Mean), is the
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 supposed to be, again?
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 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
is largely
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.
What context does
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) = (X); # 5.
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:
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:
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 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
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 get
[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 get these right, we're pretty much
doomed from the outset.
--
[EMAIL PROTECTED] (Smylers) writes:
Does that matter? This example is fairly contrived, and anybody
actually concerned about this can always use:
$num = @massive.length;
I'd be in favour of forcing people to say this if they want the length
of the array.
But then, it might be that what
Chip Salzenberg [EMAIL PROTECTED] writes:
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!
various 1-uple
1 - 100 of 258 matches
Mail list logo
