Uri Guttman wrote:
DC> Sure. Just as $42 is a shorthand for $/[42], so too $ is a
DC> shorthand for $/.
but then what about the different index bases for $42 and $/[42]? i
don't think that has been resolved (nor has mixing the $1.1 and $1[1]
syntaxes).
Bear in mind that that reply was posted i
Damian Conway wrote:
I think this error--unintentional, I swear!--argues strongly that
internal consistency within Perl 6 is more important than historical
consistency with Perl 5's $1, $2, $3...
But that's only the opinion of one(@Larry), not of $Larry.
My opinion as none(@Larry), too. And corr
On Wed, 2005-05-11 at 17:48 +1000, Damian Conway wrote:
> But it does raise an important point: the discrepancy between $42 and $/[41]
> *is* a great opportunity for off-by-on errors. Previously, however, @Larry
> have tossed back and forth the possibility of using $0 as the first capture
> var
Given:
"fail" with configurable behavior
"no fatal" to make "fail" just warn
"use fatal" to make "fail" throw exceptions
A question came up on #perl6 for the following code:
no fatal;
class Foo {
use fatal;
method bar() { fa
Aaron Sherman skribis 2005-05-11 7:44 (-0400):
> "no fatal" to make "fail" just warn
I thought it wouldn't warn, but instead silently return undef (an
unthrown exception).
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.
On 5/11/05, Aaron Sherman <[EMAIL PROTECTED]> wrote:
> Given:
>
> "fail" with configurable behavior
> "no fatal" to make "fail" just warn
Juerd is right here, it doesn't warn. Instead of "die"ing, it returns
an undef with some helpful diagnostic information (an "unthrown
exceptio
On 5/11/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> sub foo() {
> fail;
> }
>
> use fatal;
> sub bar() {
> foo(); # foo() throws exception
> }
>
> no fatal;
> sub baz() {
> foo(); # foo() returns undef
> }
>
> use fatal;
> bar(
> > But it does raise an important point: the discrepancy between $42 and $/[41]
> > *is* a great opportunity for off-by-on errors. Previously, however, @Larry
> > have tossed back and forth the possibility of using $0 as the first capture
> > variable so that the indices of $/[0], $/[1], $/[2] mat
On Wed, 2005-05-11 at 09:50, Luke Palmer wrote:
> Oh, just to avoid further confusion: In the baz() called under fatal,
> it will only turn undefs that were generated by "fail" calls into
> exceptions. Other sorts of undefs will be returned as ordinary
> undefs.
Ok, so let me try to get my head
On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote:
> Uri Guttman wrote:
>
> > DC> Sure. Just as $42 is a shorthand for $/[42], so too $ is a
> > DC> shorthand for $/.
> >
> >but then what about the different index bases for $42 and $/[42]? i
> >don't think that has been resolved (nor
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Uri Guttman wrote:
DC> Sure. Just as $42 is a shorthand for $/[42], so too $ is a
DC> shorthand for $/.
>> but then what about the different index bases for $42 and $/[42]? i
>> don't think that has been resolved (nor has mixing
On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote:
: But that's only the opinion of one(@Larry), not of $Larry.
Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens.
Our old $0 (P5's $&) could be $<> instead, short for $ or some
such.
It's already the case that p5-to-
On Wed, May 11, 2005 at 08:30:42AM -0700, Larry Wall wrote:
> On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote:
> : But that's only the opinion of one(@Larry), not of $Larry.
>
> Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens.
> Our old $0 (P5's $&) could be $<>
H,
On Wed, May 11, 2005 at 08:30:42AM -0700, Larry Wall wrote:
On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote:
: But that's only the opinion of one(@Larry), not of $Larry.
Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens.
Our old $0 (P5's $&) could be $<> inst
On Thu, May 12, 2005 at 12:06:57AM +0800, Autrijus Tang wrote:
> On Wed, May 11, 2005 at 08:30:42AM -0700, Larry Wall wrote:
> > On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote:
> > : But that's only the opinion of one(@Larry), not of $Larry.
> >
> > Let's go 0-based and make $0 =:=
Larry Wall skribis 2005-05-11 8:30 (-0700):
> It's already the case that p5-to-p6 is going to have a *wonderful*
> time translating $7 to $1[2][0]...
If I remember correctly, ** recursively flattens, and so (**$/)[7-1]
should work.
And otherwise a simple method can probably do the trick. I sugg
Larry Wall skribis 2005-05-11 8:30 (-0700):
> It's already the case that p5-to-p6 is going to have a *wonderful*
> time translating $7 to $1[2][0]...
Or maybe it just has to change "(" to "$1 := (", the second "(" to "$2
:= (", etc.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://co
We're discussing the proper semantics of (1)[0] on #perl6. Here's
where we're at so far:
1. specialise ()[] to parse as (,)[]
2. scalars are singleton lists, so ()[] naturally
3. make (1)[0] die horribly.
We all seem to agree that #3 is least useful and probably wrong. But
there's a divide betwe
Jonathan Scott Duff wrote:
What does p6l think? (What does @Larry think?)
I favor #3 as syntax error.
But note $TSa == all( none(@Larry), one($p6l) ) or so :)
--
TSa (Thomas Sandlaß)
Jonathan Scott Duff skribis 2005-05-11 11:45 (-0500):
> 1. specialise ()[] to parse as (,)[]
> 2. scalars are singleton lists, so ()[] naturally
> 3. make (1)[0] die horribly.
> #2 implies that (1)[0][0][0][0] == 1
> #1 means that (1)[0] == 1 and (1)[0][0] is an error
#1 also means that ($aref)[0]
On Wed, May 11, 2005 at 06:37:53PM +0200, Juerd wrote:
> Larry Wall skribis 2005-05-11 8:30 (-0700):
> > It's already the case that p5-to-p6 is going to have a *wonderful*
> > time translating $7 to $1[2][0]...
>
> Or maybe it just has to change "(" to "$1 := (", the second "(" to "$2
> := (", et
On Wed, May 11, 2005 at 12:01:35PM -0500, Patrick R. Michaud wrote:
> Of course, this now begs the question -- where are things stored
> after doing ... ?
>
> rx :perl5 / (don't) (ray) (me) (for solar) /
>
> My guess is that within the rule they're $1, $2, $3, etc. as before,
Within the rule
On 5/11/05, Juerd <[EMAIL PROTECTED]> wrote:
> Jonathan Scott Duff skribis 2005-05-11 11:45 (-0500):
> > 1. specialise ()[] to parse as (,)[]
> > 2. scalars are singleton lists, so ()[] naturally
> > 3. make (1)[0] die horribly.
> > #2 implies that (1)[0][0][0][0] == 1
> > #1 means that (1)[0] == 1
My perspective from PDL is that "(1)[0][0][0]"..."[0]" should evaluate
to 1. The artificial distinction between a scalar and an array of
length 1 (in each dimension) is the source of endless hassles, and it's
a pretty simple DWIM to allow indexing of element 0 of any unused
dimension. That ma
On Wed, 2005-05-11 at 12:45, Jonathan Scott Duff wrote:
> We're discussing the proper semantics of (1)[0] on #perl6. Here's
> where we're at so far:
>
> 1. specialise ()[] to parse as (,)[]
> 2. scalars are singleton lists, so ()[] naturally
> 3. make (1)[0] die horribly.
It may or may not help,
> On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote:
> : But that's only the opinion of one(@Larry), not of $Larry.
>
> Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens.
> Our old $0 (P5's $&) could be $<> instead, short for $ or some
> such.
Why can't bare $/ jus
On Wed, May 11, 2005 at 06:35:36PM +0200, Juerd wrote:
: Larry Wall skribis 2005-05-11 8:30 (-0700):
: > It's already the case that p5-to-p6 is going to have a *wonderful*
: > time translating $7 to $1[2][0]...
:
: If I remember correctly, ** recursively flattens, and so (**$/)[7-1]
: should work
On Wed, May 11, 2005 at 11:45:12AM -0500, Jonathan Scott Duff wrote:
:
: We're discussing the proper semantics of (1)[0] on #perl6. Here's
: where we're at so far:
:
: 1. specialise ()[] to parse as (,)[]
: 2. scalars are singleton lists, so ()[] naturally
: 3. make (1)[0] die horribly.
:
: We a
On Wed, May 11, 2005 at 01:11:45PM -0700, Larry Wall wrote:
> On Wed, May 11, 2005 at 11:45:12AM -0500, Jonathan Scott Duff wrote:
> :
> : We're discussing the proper semantics of (1)[0] on #perl6. Here's
> : where we're at so far:
> :
> : 1. specialise ()[] to parse as (,)[]
> : 2. scalars are s
Three years ago I wrote a simple Perl 5 script to convert the EBNF
specification of XML to Perl 6's rules.
Pugs supports rules now, so perhaps it can be tested. This is a complex
job (because it's a complex grammar, and of course it can never work
without much tweaking, and debugging grammars is p
In a somewhat related topic:
pugs> (1,(2,3),4)[2]
4
Because the invocant to .[] assumes a Singular context.
I'm not sure how any invocant can assume a Plural context anyway,
so this behaviour seems correct. Is it, though? :)
Thanks,
/Autrijus/
pgpihJttxQxy9.pgp
Description: PGP signat
On 5/11/05, Autrijus Tang <[EMAIL PROTECTED]> wrote:
> In a somewhat related topic:
>
> pugs> (1,(2,3),4)[2]
> 4
>
> Because the invocant to .[] assumes a Singular context.
Right, but the *inside* of the invocant is still a list, so it's in
list context. I think that line should return
On Wed, May 11, 2005 at 03:00:15PM -0600, Luke Palmer wrote:
> On 5/11/05, Autrijus Tang <[EMAIL PROTECTED]> wrote:
> > In a somewhat related topic:
> >
> > pugs> (1,(2,3),4)[2]
> > 4
> >
> > Because the invocant to .[] assumes a Singular context.
>
> Right, but the *inside* of the invoc
On Thu, May 12, 2005 at 04:19:02AM +0800, Autrijus Tang wrote:
: Hm? Under #2, no matter whether @foo is (1) or (1,2), the construct
: (@foo)[0] would always means @foo.[0]. Not sure how the length of @foo
: matters here.
Tell you what, let's require P5's (...)[] to be translated to [...][],
so
On Wed, May 11, 2005 at 02:12:41PM -0700, Larry Wall wrote:
> On Thu, May 12, 2005 at 04:19:02AM +0800, Autrijus Tang wrote:
> : Hm? Under #2, no matter whether @foo is (1) or (1,2), the construct
> : (@foo)[0] would always means @foo.[0]. Not sure how the length of @foo
> : matters here.
>
> Te
All~
On 5/11/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> On 5/11/05, Autrijus Tang <[EMAIL PROTECTED]> wrote:
> > In a somewhat related topic:
> >
> > pugs> (1,(2,3),4)[2]
> > 4
> >
> > Because the invocant to .[] assumes a Singular context.
>
> Right, but the *inside* of the invocant is
On Thu, May 12, 2005 at 05:19:11AM +0800, Autrijus Tang wrote:
: Sure (and done). Now that #1 is eliminated, the question is now
: whether a simple scalar can be treated as a small (one-element) array
: reference, much like a simple pair can be treated as a small
: (one-element) hash reference.
:
Larry decreed:
Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens.
Huzzah!
Our old $0 (P5's $&) could be $<> instead, short for $ or some
such.
According to the new capture semantics document posted earlier this week:
A successful match returns a C object whose ...
string
Larry mused:
I'm wondering if it's just a cardinal/ordinal thing, and we can just
translate $7 to $<7th>. Then we don't have to guess where to insert
a .flat or :flat.
That's a very interesting generalization. There are plenty of *other* cases
where one wants an ordinal, or some other kind of $n-
On Wed, 2005-05-11 at 17:48, Matt Fowles wrote:
> On 5/11/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> > On 5/11/05, Autrijus Tang <[EMAIL PROTECTED]> wrote:
> > > In a somewhat related topic:
> > >
> > > pugs> (1,(2,3),4)[2]
> > > 4
> > >
> > > Because the invocant to .[] assumes a Singul
Damian Conway wrote:
print @array[1st..($n)th];
Sounds cool, but what about $n = 0; ?
- Fagzal
On Thu, May 12, 2005 at 12:37:06AM +0200, Fagyal Csongor wrote:
> Damian Conway wrote:
>
> >print @array[1st..($n)th];
>
> Sounds cool, but what about $n = 0; ?
Then it would be 0..-1, an empty range.
/Autrijus/
pgpW4KeLIp7hR.pgp
Description: PGP signature
Autrijus Tang wrote:
On Thu, May 12, 2005 at 12:37:06AM +0200, Fagyal Csongor wrote:
Damian Conway wrote:
print @array[1st..($n)th];
Sounds cool, but what about $n = 0; ?
Then it would be 0..-1, an empty range.
Yep, but I mean in general isn't it confusing that the 0th elem
On Wed, May 11, 2005 at 03:00:15PM -0600, Luke Palmer wrote:
> On 5/11/05, Autrijus Tang <[EMAIL PROTECTED]> wrote:
> > In a somewhat related topic:
> >
> > pugs> (1,(2,3),4)[2]
> > 4
> >
> > Because the invocant to .[] assumes a Singular context.
>
> Right, but the *inside* of the invoc
(reformatted to keep initialization with test)
Autrijus Tang skribis 2005-05-12 7:04 (+0800):
> my @a = (1,2,[3,4]);
> is([EMAIL PROTECTED], 3, 'Array length, nested []');
ok 1
> my $a = (1,2,[3,4]);
> is(+$a, 3, 'Array ref length, nested []');
ok 2
> my @b = [1,
On Wed, May 11, 2005 at 11:45:12AM -0500, Jonathan Scott Duff wrote:
> We're discussing the proper semantics of (1)[0] on #perl6. Here's
> where we're at so far:
>
> 1. specialise ()[] to parse as (,)[]
> 2. scalars are singleton lists, so ()[] naturally
> 3. make (1)[0] die horribly.
(1)[0] mean
> That's a very interesting generalization. There are plenty of *other*
cases
where one wants an ordinal, or some other kind of $n-1 value. If C
(and
C, C, C) was a "subtract one" operator, you could write:
my $n = prompt "How many elems? ";
print @array[1st.
On Thu, May 12, 2005 at 07:04:48AM +0800, Autrijus Tang wrote:
: Please sanity-check. :-)
Looks good to me. Though that should perhaps not be confused with sanity.
Larry
On Wed, May 11, 2005 at 06:24:38PM -0400, Aaron Sherman wrote:
: I'm confused as well. How does that play with Larry's comment:
:
:
http://groups-beta.google.com/group/perl.perl6.language/browse_frm/thread/54a1135c012b97bf/d17b4bc5ae7db058?q=list+comma&rnum=5&hl=en#d17b4bc5ae7db058
Well, that ap
I now have a basic implementation for enumerated character classes in
the grammar engine (i.e., <[xyz]>, <-[xyz]>, <[x..z]>, and <-[x..z]>).
I didn't see it specified anywhere, but are the \d, \D, \s, \S, etc.
metacharacters still supposed to work inside of a enumerated character
class, as they
I'm working on an annotated version of the mailing list so that old
postings can be more easily researched. My very primitive implementation
is:
http://www.ajs.com/~ajs/cgi-bin/p6l-index.cgi
The input datafile is:
http://www.ajs.com/~ajs/p6l.dat
I'm using Google Groups as a back
51 matches
Mail list logo