# New Ticket Created by Tyler Curtis
# Please include the string: [perl #77022]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=77022 >
[1:38pm] tylercurtis: rakudo: grammar Foo { token TOP { 'b' } }; say
Foo.parse('abc').Bo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #77026]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=77026 >
rakudo: my $a = class { has $a; }; say $a.new(a => 1).perl; #
that looks funny too...
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #77024]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=77024 >
rakudo: class Foo::Bar {}; say Foo::Bar.new.perl; # Oh, btw is
that ; correct?
rakudo
On Thu, Aug 5, 2010 at 2:43 PM, Tyler Curtis wrote:
> On Thu, Aug 5, 2010 at 12:28 PM, Aaron Sherman wrote:
> > While that's a nifty special case (I'm sure it will surprise me someday,
> and
> > I'll spend a half hour debugging before I remember this mail), it doesn't
> > help in the general cas
# New Ticket Created by Lithos
# Please include the string: [perl #77016]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=77016 >
Hi!
The following makes rakudo hang with 100% CPU load here.
Lithos
This is Rakudo Perl 6,
# New Ticket Created by Lithos
# Please include the string: [perl #77014]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=77014 >
Hi!
Integer literals >int32 seem to overflow on my machine without any
warning or error.
Lit
# New Ticket Created by Paweł Pabian
# Please include the string: [perl #77006]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=77006 >
This works fine:
[17:05] rakudo: grammar A {token t { ^\d\d$ }; }; say "OK" if
A.pars
David Green wrote:
On 2010-08-05, at 8:27 am, Aaron Sherman wrote:
On Thu, Aug 5, 2010 at 7:55 AM, Carl Mäsak wrote:
I see this particular thinko a lot, though. Maybe some Perl 6 lint tool
or another will detect when you have a regex containing ^ at its start, $
at the end, | somewhere in the
On Thu, Aug 5, 2010 at 12:28 PM, Aaron Sherman wrote:
> While that's a nifty special case (I'm sure it will surprise me someday, and
> I'll spend a half hour debugging before I remember this mail), it doesn't
> help in the general case (see my example grammar, below).
In the general case, no. In
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #77010]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=77010 >
rakudo: sub postfix:($n) { [*] 1..$n }; say (1, 2, 3)>>!
rakudo 19931f: OUTPUT«===SORR
On Thu, Aug 5, 2010 at 11:09 AM, Patrick R. Michaud wrote:
> On Thu, Aug 05, 2010 at 10:27:50AM -0400, Aaron Sherman wrote:
> > On Thu, Aug 5, 2010 at 7:55 AM, Carl Mäsak wrote:
> > > I see this particular thinko a lot, though. Maybe some Perl 6 lint
> > > tool or another will detect when you hav
On Wed, Aug 4, 2010 at 6:20 AM, Jonathan Scott Duff wrote:
> Perhaps, as an optimization, we could create another multi for infix:<...>
> that fires to infix:<..> only when the list on either side only contains 1
> element and that element is an Int. Something like:
>
> our multi sub infix:<...>(
On Thu, Aug 05, 2010 at 10:27:50AM -0400, Aaron Sherman wrote:
> On Thu, Aug 5, 2010 at 7:55 AM, Carl Mäsak wrote:
> > I see this particular thinko a lot, though. Maybe some Perl 6 lint
> > tool or another will detect when you have a regex containing ^ at its
> > start, $ at the end, | somewhere i
On 2010-08-05, at 8:27 am, Aaron Sherman wrote:
> On Thu, Aug 5, 2010 at 7:55 AM, Carl Mäsak wrote:
>>
>> I see this particular thinko a lot, though. Maybe some Perl 6 lint tool or
>> another will detect when you have a regex containing ^ at its start, $ at
>> the end, | somewhere in the middle
Aaron Sherman wrote:
> You know, this problem would go away, almost entirely, if we had a :f[ull]
> adverb for regex matching that imposed ^[...]$ around the entire match. Then
> your code becomes:
>
> m:f/<[A..Z]>+|<[a..z]>+/
>
> for grins, :f[ull]l[ine] could use ^^ and $$.
>
> I suspect :full w
On Thu, Aug 5, 2010 at 7:55 AM, Carl Mäsak wrote:
> Darren (), Carl (>>>), Darren (>>), Patrick (>):
>
> > In this case yes -- the original pattern without the square brackets
> > would act like:
> >
> >/ [^ <[A..Z]>+] | [<[a..z]>+ $] /
> >
> > In other words, the original pattern says "s
Darren (), Carl (>>>), Darren (>>), Patrick (>):
>> >>Read what I said again. I was proposing that the namespace comprised of
>> >>names matching a pattern like this:
>> >>
>> >> /^ <[A..Z]>+ | <[a..z]>+ $/
>> >
>> >/^ [<[A..Z]>+ | <[a..z]>+] $/
>>
>> Are the square brackets necessary when the
On Thu, Aug 05, 2010 at 12:29:38AM -0700, Darren Duncan wrote:
> Carl Mäsak wrote:
> >Darren (>):
> >>Read what I said again. I was proposing that the namespace comprised of
> >>names matching a pattern like this:
> >>
> >> /^ <[A..Z]>+ | <[a..z]>+ $/
> >
> >/^ [<[A..Z]>+ | <[a..z]>+] $/
>
> Are
Now fixed in b627e33. Assigning to moritz for spectest verification.
Thanks!
Pm
Darren Duncan wrote:
For another thing, assuming in the typical case that any time a language
evolves, it still provides the means to accomplish anything it was
previously capable of, then each implementation needs no
backwards-compatibility internally, but just the state of the art.
Backward
Damian Conway wrote:
Darren suggested:
Use namespaces.
The upper/lower/mixed approach *is* a
namespace approach.
Yes it is. But I thought that prefix-namespaces would scale better. Especially
if the documentation system got complicated enough to involve modules, possibly
those by differ
Carl Mäsak wrote:
Darren (>):
Read what I said again. I was proposing that the namespace comprised of
names matching a pattern like this:
/^ <[A..Z]>+ | <[a..z]>+ $/
/^ [<[A..Z]>+ | <[a..z]>+] $/
Are the square brackets necessary when the pattern doesn't contain anything
other than the a
Darren (>):
> Read what I said again. I was proposing that the namespace comprised of
> names matching a pattern like this:
>
> /^ <[A..Z]>+ | <[a..z]>+ $/
/^ [<[A..Z]>+ | <[a..z]>+] $/
// Carl
23 matches
Mail list logo
