Re: Is there another way to define a regex?

[Gianni Ceccarelli]

On 2016-01-17 Tom Browder  wrote:
> My question: Is there a way to have Perl 6 do the required escaping
> for the regex programmatically, i.e., turn this:
> 
> my $str = '/home/usr/.cpan';
> 
> into this:
> 
> my regex dirs {
>   \/home\/usr\/\.cpan
> }
> 
> automatically?  

Yes! And it's also simpler than in Perl 5. I Perl 5, you would have to
do something like:

  my $dirs = qr{\Q$str};

but in Perl 6 you just do:

  my $dirs = regex { $str };

because the other behaviour, to interpret the contents of $str as
another regex to match, has more explicit syntax:

  regex { <$another_regex> }

For your initial use-case there is also another shortcut: an array is
interpreted as an alternation, so you could write:

  my @dirs = < /home/user/.cpan /home/tbrowde/.emacs >;
  my $regex = regex { @dirs };

and it would do what your Perl 5 example does.

If you want to be more restrictive, you can anchor the alternation:
  
  my $regex = regex { ^ @dirs };

Here is a complete program:

  use v6;

  my @dirs = < foo bar baz >;

  my $matcher = regex { ^ @dirs $ };

  for $*IN.lines -> $line {
  if $line ~~ $matcher {
  say "<$line> matched";
  }
  else {
  say "<$line> didn't match";
  }
  }

-- 
Dakkar - 
GPG public key fingerprint = A071 E618 DD2C 5901 9574
 6FE2 40EA 9883 7519 3F88
key id = 0x75193F88

To spot the expert, pick the one who predicts the job will take the
longest and cost the most.

[perl6/specs] 73ff49: META doesn't need an entire glossary to itself

[GitHub]

  Branch: refs/heads/meta-v1
  Home:   https://github.com/perl6/specs
  Commit: 73ff494a2b3c051a9cabd97a0a7ebc874aa7aa29
  
https://github.com/perl6/specs/commit/73ff494a2b3c051a9cabd97a0a7ebc874aa7aa29
  Author: Anthony Parsons 
  Date:   2016-01-17 (Sun, 17 Jan 2016)

  Changed paths:
M S22-package-format.pod

  Log Message:
  ---
  META doesn't need an entire glossary to itself

There's a document-level one right above it. Merged the two.

[perl6/specs] 216855: [S04] Add missing parenthesis in zip() example

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 2168554941a2c85b7c3a1512382a965aa3139258
  
https://github.com/perl6/specs/commit/2168554941a2c85b7c3a1512382a965aa3139258
  Author: Sterling Hanenkamp 
  Date:   2016-01-16 (Sat, 16 Jan 2016)

  Changed paths:
M S04-control.pod

  Log Message:
  ---
  [S04] Add missing parenthesis in zip() example


  Commit: 21525aab69789f0d7a00640d75ae332d4fad9e73
  
https://github.com/perl6/specs/commit/21525aab69789f0d7a00640d75ae332d4fad9e73
  Author: niner 
  Date:   2016-01-17 (Sun, 17 Jan 2016)

  Changed paths:
M S04-control.pod

  Log Message:
  ---
  Merge pull request #105 from zostay/zip-parens

[S04] Add missing parenthesis in zip() example


Compare: https://github.com/perl6/specs/compare/b0657be1c92e...21525aab6978

Re: Is there another way to define a regex?

[Nelo Onyiah]

Curious but are the non capturing groups necessary?
On 17 Jan 2016 11:35 p.m., "Tom Browder"  wrote:

> On Sun, Jan 17, 2016 at 3:03 PM, Moritz Lenz  wrote:
> > On 01/17/2016 06:07 PM, Tom Browder wrote:
> ...
> >> # regex of dirs to ignore
> >> my regex dirs {
> >>   \/home\/user\/\.cpan |
> >>   \/home\/tbrowde\/\.emacs
> >> }
> >
> > Better written as
> >
> > my regex dirs {
> >| '/home/user/.cpan'
> >| '/home/tbowde/.emacs'
> > }
> >
> > Yes, quoting does now work in regexes too. Cool, right? :-)
>
> Yes, very cool!  I have decided to use that format and it does ease
> adding or modifying entries.
>
> My final regex looks like this (shortened to only a couple of entries):
>
> my regex dirs {
>   ^
>   \s*
>   [# <= non-capture grouping
>| '/home/user/.cpan'
>| '/home/tbowde/.emacs'
># more entries...
>   ]
> }
>
> used like this:
>
>   next LINE if $line ~~ //;
>
> Thanks, Moritz!
>
> Best,
>
> -Tom
>

[perl #127297] [BUG] The Supply.grep Supply reverts to the original Supply on a subsequent .grep

[via RT]

# New Ticket Created by  Jonathan Stowe 
# Please include the string:  [perl #127297]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=127297 >


If the second grep was working on the result of the first this would not output 
anything:

install/bin/perl6 -e 'Supply.from-list().grep(/foo/).grep(/baz/).tap({say $_})'
baz

Instead it outputs "baz" which is a valid value from the original Supply.

Having bisected this was definitely introduced with 
a8231f14b2d5400e0653aac453496e00318142c5 which was where the majority of the 
changes to supplies went in.

It is still present in 

This is Rakudo version 2015.12-111-gfec0619 built on MoarVM version 2015.12
implementing Perl 6.c

which is where I detected it, and HEAD as of today.

I noticed this first in trying to fix Net::AMQP in the ecosystem, here it greps 
for AMQP frames which represent methods and reformats them to a hash with the 
method as a key, a subsequent attempt to further grep the resulting supply is 
fatal because it reverts to being raw AMQP frames as per the original supply.

I can add a test to roast if necessary.

[perl #127306] type captures in return type is not resolved

[via RT]

# New Ticket Created by  Wenzel Peppmeyer 
# Please include the string:  [perl #127306]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=127306 >


sub foo(::T $t --> T){ T.new };
my Int $i = 42;
foo($i);

# OUTPUT«Type check failed for return value; expected T but got Int␤  in 
# sub foo at /tmp/HqdmxVFmny line 1␤  in block  at /tmp/HqdmxVFmny 
# line 1␤␤»

[perl #127305] EXPORT ignored when unit module/package is used

[jn...@jnthn.net via RT]

On Sun Jan 17 22:29:57 2016, gfldex wrote:
> # https://gist.github.com/b0d44595e0d3b314a09d
> 
> # Module.pm6
> unit module Module;
> 
> sub EXPORT ($var) {
> { foo => sub () {} }
> }
> 
> # use-module.p6
> 
> use v6;
> use lib '.';
> use Module 42;
> 
> # OUTPUT:
> # Error while importing from 'Module':
> # no EXPORT sub, but you provided positional argument in the 'use'
> statement
> # at /home/dex/projekte/perl6/rakudobug/EXPORT+unit-package/use-
> module.p6:3
> # --> use Module 42⏏;
> 
> # Package.pm6
> 
> unit package Package;
> 
> sub EXPORT ($var) {
> { foo => sub () {} }
> }
> 
> # use-package.p6
> 
> use v6;
> use lib '.';
> use Package 42;
> 
> # OUTPUT:
> # Error while importing from 'Package':
> # no EXPORT sub, but you provided positional argument in the 'use'
> statement
> # at /home/dex/projekte/perl6/rakudobug/EXPORT+unit-package/use-
> package.p6:3
> # --> use Package 42⏏;
> 
> # expected: either complain about unit and EXPORT in the same file or
> # make it work

 must be in the outermost lexical scope of the compilation unit. 
Which...uh...it appears it should be here! I suspect the compiler is sneaking a 
secret extra scope in as a result of the unit declaration. Can we fix that? Yes 
for module/class/grammar. But for roles, not really as they're generic and the 
parameter has to go somewhere. But that makes a weird discontinuity. Hmmm. :-)

Re: Workaround for Perl 5's __DATA__

[Tom Browder]

On Mon, Jan 18, 2016 at 6:47 AM, Kamil Kułaga  wrote:
> You may be happy with =finish block
...

Thanks, Kamil!

-Tom

'!' versus 'not' in boolean expression

[Tom Browder]

In creating some new Perl 6 programs I've run across several instances
I'm confused about, to wit:

Example 1
---

> my %h; say 'false' if !%h:exists;
Unexpected named parameter 'exists' passed

Example 2
---

> my %h; say 'false' if not %h:exists;
false

It looks like '!' doesn't work as I thought it was supposed to.  But,
I just discovered that when I use parens, it works.

Example 3
---

> my %h; say 'false' if !(%h:exists);
false

I presume the parens would cure the similar things I've noticed with
other classes.

When I look at the docs on Operators I see this:


prefix !

multi sub prefix:(Mu) returns Bool:D

Negated boolean context operator.

Coerces the argument to Bool by calling the Bool method on it, and
returns the negation of the result. Note that this collapses
Junctions.



prefix not

multi sub prefix:(Mu $x) returns Bool:D

Evaluates its argument in boolean context (and thus collapses
Junctions), and negates the result.


Those two definitions look very similar to my eyes, but I think the
subtle difference is intentional.But they are not identical.

Is there some rule of thumb here that a Perl 6 wannabe can grasp in
Perl 5 terms (e.g., prefer 'not' over '!')?  Or am I going to have to
go deep early into the object class structure?

Many thanks.

-Tom

[perl #127292] [BUG] cannot bind private hash attribute with key type constraint

[via RT]

# New Ticket Created by  rightfold 
# Please include the string:  [perl #127292]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=127292 >


Consider the following code:

class C {
  has %!h{Pair};

  method m {
%!h := %!h.clone;
  }
}

C.new.m;

rather than succeeding, it fails with:

> Type check failed in binding; expected Associative[Any,Pair] but got 
> Hash[Any,Pair]
>  in method m at /tmp/clone.p6 line 4
>  in block  at /tmp/clone.p6 line 9

Removing "{Pair}" from the code makes the code work, however.

Rakudo version:

> This is Rakudo version 2015.12 built on MoarVM version 2015.12 implementing 
> Perl 6.c.

Re: Workaround for Perl 5's __DATA__

[Kamil Kułaga]

You may be happy with =finish block

use v6;

say $=finish.split("\n").perl;


=finish
_
I like pancakes
And apples

On Sat, Jan 16, 2016 at 8:07 PM, Tom Browder  wrote:
> I have tried this in my Perl 6 code (v6.c):
>
> =begin DATA
> blah
> blah2
> =end DATA
>
> Then:
>
> for $=DATA.lines -> $line {
>   # process a line
> }
>
> but I get this message:
>
> Pod variable @=DATA not yet implemented. Sorry.
>
> Is there any workaround for this other than putting the data in an array?
>
> Thanks.
>
> Best regards,
>
> -Tom



-- 
Pozdrawiam

Kamil Kułaga

Re: Is there another way to define a regex?

[Tom Browder]

On Sunday, January 17, 2016, Nelo Onyiah  wrote:

> Curious but are the non capturing groups necessary?
>
I don't know the answer for the Perl 6 construct but I think the grouping
is required in the Perl 5 equivalent.  But I certainly may be wrong.  Now
that you mention it, I think you are probably correct.

Thanks for pointing that out.

-Tom

Re: '!' versus 'not' in boolean expression

[yary]

In Perl5, there's "&&" vs "and", "||" vs "or", "^" vs "xor", and "!"
vs "not", the difference being precedence. Perhaps it's the same with
Perl6...

Re: '!' versus 'not' in boolean expression

[Elizabeth Mattijsen]

> On 18 Jan 2016, at 19:55, Tom Browder  wrote:
> 
> In creating some new Perl 6 programs I've run across several instances
> I'm confused about, to wit:
> 
> Example 1
> ---
> 
>> my %h; say 'false' if !%h:exists;
> Unexpected named parameter 'exists’ passed

Yeah, this is an unexpected one.  However, there is a simple solution:

  my %h; say 'false' if %h:!exists;

In general, :foo is equivalent to foo => True, and :!foo is equivalent to foo 
=> False.


> Example 2
> ---
> 
>> my %h; say 'false' if not %h:exists;
> false
> 
> It looks like '!' doesn't work as I thought it was supposed to.  But,
> I just discovered that when I use parens, it works.

Yes, the ! binds closer, and eats the :exists, and then complains about it.



Liz

Re: [perl #127305] EXPORT ignored when unit module/package is used

[Lloyd Fournier]

I am going to sneak in a docs discussion into this ticket with regards to
EXPORT some relevant parties are here.

http://docs.perl6.org/language/modules#EXPORT

I mentioned when I wrote it:
"Note, EXPORT can't be declared inside a package because presently rakudo
(2015.09) seems to treat EXPORT as part of the compunit rather than the
package."

Of course, happy for that to change. With my more nuanced understanding of
this I could re-write this as:

"for EXPORT to be called it must be defined at UNIT:: Therefore it
cannot be defined inside a package".

Maybe if a package is declared as UNIT, all its lexical symbols could be
inserted both into the package and UNIT.

gfldex, I see you've edited the second EXPORT example, but to me it's made
it much less clear what's going on. I see where you are going, trying to
show that the power of ::T type captures can still be used in EXPORT, but I
think we should leave that up to the imagination of the user. EXPORT is
just a sub after all so those features are naturally there. Perhaps that
example could go into a "cookbook" type thing.

Thanks!

On Tue, Jan 19, 2016 at 5:03 AM jn...@jnthn.net via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Sun Jan 17 22:29:57 2016, gfldex wrote:
> > # https://gist.github.com/b0d44595e0d3b314a09d
> >
> > # Module.pm6
> > unit module Module;
> >
> > sub EXPORT ($var) {
> > { foo => sub () {} }
> > }
> >
> > # use-module.p6
> >
> > use v6;
> > use lib '.';
> > use Module 42;
> >
> > # OUTPUT:
> > # Error while importing from 'Module':
> > # no EXPORT sub, but you provided positional argument in the 'use'
> > statement
> > # at /home/dex/projekte/perl6/rakudobug/EXPORT+unit-package/use-
> > module.p6:3
> > # --> use Module 42⏏;
> >
> > # Package.pm6
> >
> > unit package Package;
> >
> > sub EXPORT ($var) {
> > { foo => sub () {} }
> > }
> >
> > # use-package.p6
> >
> > use v6;
> > use lib '.';
> > use Package 42;
> >
> > # OUTPUT:
> > # Error while importing from 'Package':
> > # no EXPORT sub, but you provided positional argument in the 'use'
> > statement
> > # at /home/dex/projekte/perl6/rakudobug/EXPORT+unit-package/use-
> > package.p6:3
> > # --> use Package 42⏏;
> >
> > # expected: either complain about unit and EXPORT in the same file or
> > # make it work
>
>  must be in the outermost lexical scope of the compilation unit.
> Which...uh...it appears it should be here! I suspect the compiler is
> sneaking a secret extra scope in as a result of the unit declaration. Can
> we fix that? Yes for module/class/grammar. But for roles, not really as
> they're generic and the parameter has to go somewhere. But that makes a
> weird discontinuity. Hmmm. :-)
>
>

Re: [perl #126818] on "is cached" subs: getlex: outer index out of range

[Lloyd Fournier]

This bug just hit me :\. It should go away with 'no precompilation'.

I believe it's closely related to:

https://rt.perl.org/Public/Bug/Display.html?id=125634

On Tue, Dec 8, 2015 at 2:43 AM Zoffix Znet 
wrote:

> # New Ticket Created by  Zoffix Znet
> # Please include the string:  [perl #126818]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=126818 >
>
>
> Steps to reproduce:
> #
> $ cat > Foo.pm;
> unit module Foo;
> our sub foo () is cached { 42 }
> $ perl6 -I. -MFoo -e 'say Foo::foo'
> getlex: outer index out of range
>   in any enter at gen/moar/m-Metamodel.nqp:3763
>   in block  at -e:1
> #
>
> The problem goes away if "is cached" trait is removed.
>

Re: '!' versus 'not' in boolean expression

[James Ellis Osborne III]

Too many Reimanns & Not enough role?

-jas

On 18 January 2016 at 11:37, Elizabeth Mattijsen  wrote:
>
>> On 18 Jan 2016, at 19:55, Tom Browder  wrote:
>>
>> In creating some new Perl 6 programs I've run across several instances
>> I'm confused about, to wit:
>>
>> Example 1
>> ---
>>
>>> my %h; say 'false' if !%h:exists;
>> Unexpected named parameter 'exists’ passed
>
> Yeah, this is an unexpected one.  However, there is a simple solution:
>
>   my %h; say 'false' if %h:!exists;
>
> In general, :foo is equivalent to foo => True, and :!foo is equivalent to foo 
> => False.
>
>
>> Example 2
>> ---
>>
>>> my %h; say 'false' if not %h:exists;
>> false
>>
>> It looks like '!' doesn't work as I thought it was supposed to.  But,
>> I just discovered that when I use parens, it works.
>
> Yes, the ! binds closer, and eats the :exists, and then complains about it.
>
>
>
> Liz

Re: '!' versus 'not' in boolean expression

[Tom Browder]

On Mon, Jan 18, 2016 at 1:37 PM, Elizabeth Mattijsen  wrote:
>> On 18 Jan 2016, at 19:55, Tom Browder  wrote:
>> In creating some new Perl 6 programs I've run across several instances
>> I'm confused about, to wit:
>>
>> Example 1
>> ---
>>
>>> my %h; say 'false' if !%h:exists;
>> Unexpected named parameter 'exists’ passed
>
> Yeah, this is an unexpected one.  However, there is a simple solution:
>
>   my %h; say 'false' if %h:!exists;
>
> In general, :foo is equivalent to foo => True, and :!foo is equivalent to foo 
> => False.

Okay, I'll just have to get used to it, then.

Thanks, Liz!

-Tom