Re: Is this a bug?

[Aaron Sherman]

Thank you. Silly me, thinking "this is so simple I don't need to run it
through the command-line to test it." :-)

Anway, yeah,

 say $_ for reverse lines



Aaron Sherman, M.:
P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
Toolsmith, developer, gamer and life-long student.


On Mon, Sep 19, 2016 at 10:10 AM, Timo Paulssen  wrote:

> On 19/09/16 16:02, Aaron Sherman wrote:
> > I'm guessing that what you meant was "say as a function was what I >
> meant to use there." In which case: > > say for reverse lines > > or > >
> for reverse lines { say } > > These are both valid ways of asking for each
> element of the iterable > thing returned from lines to be printed with a
> newline.
> Watch out, this needs to read say $_ otherwise you would get an error
> message:
>
> Unsupported use of bare "say"; in Perl 6 please use .say if you meant $_,
> or use an explicit invocant or argument, or use  to refer to the
> function as a noun
>
>

Re: Is this a bug?

[Parrot Raiser]

It may make it clearer if I explain the broader objective. I'm trying
to learn P6 thoroughly by developing training courses to teach it from
scratch. (Fans of Gerald Weinberg may recognise the idea.) Obviously,
while doing so, I want to explore pathological cases, both to clarify
the concepts and to anticipate the mistakes that students might make.
Sometimes, it's necessary to do so to resolve ambiguities in whatever
sources are available.

The language is far too deep and complex to absorb in one pass, and
contains a great deal which is of interest to advanced system software
developers, but not to someone who just wants to do some simple
processing or file manipulation. My aim is to develop a series of
successively deeper courses, each of which will be complete within
itself. The first level is procedural. O-O is the next.

Topics should proceed logically from the basics, each building on the
previous, without having to drag in extraneous topics or diversions.
(Examples should not require forward references or bouncing around in
the text.) That's why I don't want to introduce .say at this stage, if
I can help it.

On 9/18/16, Trey Harris  wrote:
> On Sun, Sep 18, 2016 at 16:49 Parrot Raiser <1parr...@gmail.com> wrote:
>
> say { $_ } was the correct thing to use there. (I'm trying to avoid
>> any mention of O-O for the moment.)
>>
> “Trying to avoid any mention of O-O” seems like a Perl 6 obfuscation or
> golf constraint, not a desirable development or learning goal. Perl 6
> doesn’t *force* you to write programs in an object-oriented style; you can
> do it in functional or procedural or whatever style suits you. But you’re
> going to have a bad time if you try to deny Perl 6’s fully OO nature. This
> is in stark contrast to Perl 5, where OO was bolted on, and you could say
> that the non-OO core was more “real” than the object-oriented sugar found
> in modules you had to use.
>
> Writing something like say($_) for reverse lines — which is what I think is
> closest to what you wanted — isn’t any more or less “object-oriented” than
> the more idiomatic .say for reverse lines;. In Perl 5, some rather
> byzantine rules governed the use of the implicit $_; almost all of the
> convenience afforded by those rules can be gained through the use of
> topicalized objects, so the byzantine rules are gone — but the convenience
> is gone too unless you’re willing to use the topic in the .foo style.
>
> I think perhaps you see a dot, and dot signifies OO, so the .say... version
> might *look* more OO than the say(... version in some sense, but that’s
> pretty much cosmetic. You’re *using* some objects by interacting with the
> Perl 6 core either way. It’s your choice not to write your logic in an OO
> style, but you can’t prevent OO from happening during execution.
>
> (This really isn’t some half-hearted attempt to force you into OO through
> the backdoor; you really can skip OO for all *your* logic. You just can’t
> pretend you’re not using an object-oriented language when you have to touch
> code you’re not in control of, whether an OO library or the Perl 6 core.
> But pretty much the entirety of what you need to know about OO if you
> choose to do that is various syntax and some desiderata about the calling
> semantics.)
>
> say {} was a "what happens if I do this" exercise.
>>
>> What is this  -> ;; $_? is raw { #`(Block|170303864) … } output?
>>
>> On 9/18/16, Brent Laabs  wrote:
>> > Remember you can call a block with parentheses:
>> >
>> >> say { 11 + 31 };
>> > -> ;; $_? is raw { #`(Block|140268472711224) ... }
>> >> say { 11 + 31 }();
>> > 42
>> >
>> >
>> > On Sun, Sep 18, 2016 at 12:58 PM, Elizabeth Mattijsen 
>> > wrote:
>> >
>> >> I think you want:
>> >>
>> >>   .say for reverse lines;
>> >>
>> >> not sure what you are trying to achieve otherwise, but:
>> >>
>> >>say { }
>> >>
>> >> producing something like
>> >>
>> >>-> ;; $_? is raw { #`(Block|170303864) … }
>> >>
>> >> feels entirely correct to me.   :-)
>> >>
>> >>
>> >> Liz
>> >>
>> >> > On 18 Sep 2016, at 21:52, Parrot Raiser <1parr...@gmail.com> wrote:
>> >> >
>> >> > This code:
>> >> > 1 #! /home/guru/bin/perl6
>> >> > 2
>> >> > 3 # Ask for some lines and output them in reverse
>> >> > 4 # Work out the appropriate EOF symbol for the OS
>> >> > 5
>> >> > 6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D");
>> >> > 7
>> >> > 8 say "Please enter some lines and end them with $EOF";
>> >> > 9
>> >> > 10 say { for reverse lines() {} };
>> >> > 11
>> >> > 12 # End
>> >> > produces this:
>> >> > Please enter some lines and end them with CTRL-D# obviously from
>> >> line 8
>> >> > -> ;; $_? is raw { #`(Block|170303864) ... }#
>> >> > but
>> >> this?
>> >>
>> >>
>> >
>>
> ​
>

Re: Is this a bug?

[Timo Paulssen]

On 19/09/16 16:02, Aaron Sherman wrote:
> I'm guessing that what you meant was "say as a function was what I > meant to 
> use there." In which case: > > say for reverse lines > > or
> > for reverse lines { say } > > These are both valid ways of asking
for each element of the iterable > thing returned from lines to be
printed with a newline.
Watch out, this needs to read say $_ otherwise you would get an error
message:

Unsupported use of bare "say"; in Perl 6 please use .say if you meant
$_, or use an explicit invocant or argument, or use  to refer to the
function as a noun

Re: Is this a bug?

[Aaron Sherman]

I'm guessing that what you meant was "say as a function was what I meant to
use there." In which case:

say for reverse lines

or

for reverse lines { say }

These are both valid ways of asking for each element of the iterable thing
returned from lines to be printed with a newline.

But remember that any {} around code creates a Block in Perl 6, and a Block
is a first-class object. If you ask say to print a Block, it will quite
happily try to do that.




Aaron Sherman, M.:
P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
Toolsmith, developer, gamer and life-long student.


On Sun, Sep 18, 2016 at 4:49 PM, Parrot Raiser <1parr...@gmail.com> wrote:

> say { $_ } was the correct thing to use there. (I'm trying to avoid
> any mention of O-O for the moment.)
> say {} was a "what happens if I do this" exercise.
>
> What is this  -> ;; $_? is raw { #`(Block|170303864) … } output?
>
> On 9/18/16, Brent Laabs  wrote:
> > Remember you can call a block with parentheses:
> >
> >> say { 11 + 31 };
> > -> ;; $_? is raw { #`(Block|140268472711224) ... }
> >> say { 11 + 31 }();
> > 42
> >
> >
> > On Sun, Sep 18, 2016 at 12:58 PM, Elizabeth Mattijsen 
> > wrote:
> >
> >> I think you want:
> >>
> >>   .say for reverse lines;
> >>
> >> not sure what you are trying to achieve otherwise, but:
> >>
> >>say { }
> >>
> >> producing something like
> >>
> >>-> ;; $_? is raw { #`(Block|170303864) … }
> >>
> >> feels entirely correct to me.   :-)
> >>
> >>
> >> Liz
> >>
> >> > On 18 Sep 2016, at 21:52, Parrot Raiser <1parr...@gmail.com> wrote:
> >> >
> >> > This code:
> >> > 1 #! /home/guru/bin/perl6
> >> > 2
> >> > 3 # Ask for some lines and output them in reverse
> >> > 4 # Work out the appropriate EOF symbol for the OS
> >> > 5
> >> > 6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D");
> >> > 7
> >> > 8 say "Please enter some lines and end them with $EOF";
> >> > 9
> >> > 10 say { for reverse lines() {} };
> >> > 11
> >> > 12 # End
> >> > produces this:
> >> > Please enter some lines and end them with CTRL-D# obviously from
> >> line 8
> >> > -> ;; $_? is raw { #`(Block|170303864) ... }# but
> >> this?
> >>
> >>
> >
>

Re: Is this a bug?

[Trey Harris]

On Sun, Sep 18, 2016 at 16:49 Parrot Raiser <1parr...@gmail.com> wrote:

say { $_ } was the correct thing to use there. (I'm trying to avoid
> any mention of O-O for the moment.)
>
“Trying to avoid any mention of O-O” seems like a Perl 6 obfuscation or
golf constraint, not a desirable development or learning goal. Perl 6
doesn’t *force* you to write programs in an object-oriented style; you can
do it in functional or procedural or whatever style suits you. But you’re
going to have a bad time if you try to deny Perl 6’s fully OO nature. This
is in stark contrast to Perl 5, where OO was bolted on, and you could say
that the non-OO core was more “real” than the object-oriented sugar found
in modules you had to use.

Writing something like say($_) for reverse lines — which is what I think is
closest to what you wanted — isn’t any more or less “object-oriented” than
the more idiomatic .say for reverse lines;. In Perl 5, some rather
byzantine rules governed the use of the implicit $_; almost all of the
convenience afforded by those rules can be gained through the use of
topicalized objects, so the byzantine rules are gone — but the convenience
is gone too unless you’re willing to use the topic in the .foo style.

I think perhaps you see a dot, and dot signifies OO, so the .say... version
might *look* more OO than the say(... version in some sense, but that’s
pretty much cosmetic. You’re *using* some objects by interacting with the
Perl 6 core either way. It’s your choice not to write your logic in an OO
style, but you can’t prevent OO from happening during execution.

(This really isn’t some half-hearted attempt to force you into OO through
the backdoor; you really can skip OO for all *your* logic. You just can’t
pretend you’re not using an object-oriented language when you have to touch
code you’re not in control of, whether an OO library or the Perl 6 core.
But pretty much the entirety of what you need to know about OO if you
choose to do that is various syntax and some desiderata about the calling
semantics.)

say {} was a "what happens if I do this" exercise.
>
> What is this  -> ;; $_? is raw { #`(Block|170303864) … } output?
>
> On 9/18/16, Brent Laabs  wrote:
> > Remember you can call a block with parentheses:
> >
> >> say { 11 + 31 };
> > -> ;; $_? is raw { #`(Block|140268472711224) ... }
> >> say { 11 + 31 }();
> > 42
> >
> >
> > On Sun, Sep 18, 2016 at 12:58 PM, Elizabeth Mattijsen 
> > wrote:
> >
> >> I think you want:
> >>
> >>   .say for reverse lines;
> >>
> >> not sure what you are trying to achieve otherwise, but:
> >>
> >>say { }
> >>
> >> producing something like
> >>
> >>-> ;; $_? is raw { #`(Block|170303864) … }
> >>
> >> feels entirely correct to me.   :-)
> >>
> >>
> >> Liz
> >>
> >> > On 18 Sep 2016, at 21:52, Parrot Raiser <1parr...@gmail.com> wrote:
> >> >
> >> > This code:
> >> > 1 #! /home/guru/bin/perl6
> >> > 2
> >> > 3 # Ask for some lines and output them in reverse
> >> > 4 # Work out the appropriate EOF symbol for the OS
> >> > 5
> >> > 6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D");
> >> > 7
> >> > 8 say "Please enter some lines and end them with $EOF";
> >> > 9
> >> > 10 say { for reverse lines() {} };
> >> > 11
> >> > 12 # End
> >> > produces this:
> >> > Please enter some lines and end them with CTRL-D# obviously from
> >> line 8
> >> > -> ;; $_? is raw { #`(Block|170303864) ... }# but
> >> this?
> >>
> >>
> >
>
​

Re: Is this a bug?

[Brandon Allbery]

On Sun, Sep 18, 2016 at 4:49 PM, Parrot Raiser <1parr...@gmail.com> wrote:

> What is this  -> ;; $_? is raw { #`(Block|170303864) … } output?


It's the gist of a Block, which is what you asked for when you did a `say`
on an executable block.
Why do you believe `say { $_ }` is the right thing there? What were you
expecting it to do?

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: Is this a bug?

[Elizabeth Mattijsen]

It is the .perl representation of a Block.

> On 18 Sep 2016, at 22:49, Parrot Raiser <1parr...@gmail.com> wrote:
> 
> say { $_ } was the correct thing to use there. (I'm trying to avoid
> any mention of O-O for the moment.)
> say {} was a "what happens if I do this" exercise.
> 
> What is this  -> ;; $_? is raw { #`(Block|170303864) … } output?
> 
> On 9/18/16, Brent Laabs  wrote:
>> Remember you can call a block with parentheses:
>> 
>>> say { 11 + 31 };
>> -> ;; $_? is raw { #`(Block|140268472711224) ... }
>>> say { 11 + 31 }();
>> 42
>> 
>> 
>> On Sun, Sep 18, 2016 at 12:58 PM, Elizabeth Mattijsen 
>> wrote:
>> 
>>> I think you want:
>>> 
>>>  .say for reverse lines;
>>> 
>>> not sure what you are trying to achieve otherwise, but:
>>> 
>>>   say { }
>>> 
>>> producing something like
>>> 
>>>   -> ;; $_? is raw { #`(Block|170303864) … }
>>> 
>>> feels entirely correct to me.   :-)
>>> 
>>> 
>>> Liz
>>> 
 On 18 Sep 2016, at 21:52, Parrot Raiser <1parr...@gmail.com> wrote:
 
 This code:
 1 #! /home/guru/bin/perl6
 2
 3 # Ask for some lines and output them in reverse
 4 # Work out the appropriate EOF symbol for the OS
 5
 6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D");
 7
 8 say "Please enter some lines and end them with $EOF";
 9
 10 say { for reverse lines() {} };
 11
 12 # End
 produces this:
 Please enter some lines and end them with CTRL-D# obviously from
>>> line 8
 -> ;; $_? is raw { #`(Block|170303864) ... }# but
>>> this?
>>> 
>>> 
>> 

Re: Is this a bug?

[Brent Laabs]

Remember you can call a block with parentheses:

> say { 11 + 31 };
-> ;; $_? is raw { #`(Block|140268472711224) ... }
> say { 11 + 31 }();
42


On Sun, Sep 18, 2016 at 12:58 PM, Elizabeth Mattijsen 
wrote:

> I think you want:
>
>   .say for reverse lines;
>
> not sure what you are trying to achieve otherwise, but:
>
>say { }
>
> producing something like
>
>-> ;; $_? is raw { #`(Block|170303864) … }
>
> feels entirely correct to me.   :-)
>
>
> Liz
>
> > On 18 Sep 2016, at 21:52, Parrot Raiser <1parr...@gmail.com> wrote:
> >
> > This code:
> > 1 #! /home/guru/bin/perl6
> > 2
> > 3 # Ask for some lines and output them in reverse
> > 4 # Work out the appropriate EOF symbol for the OS
> > 5
> > 6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D");
> > 7
> > 8 say "Please enter some lines and end them with $EOF";
> > 9
> > 10 say { for reverse lines() {} };
> > 11
> > 12 # End
> > produces this:
> > Please enter some lines and end them with CTRL-D# obviously from
> line 8
> > -> ;; $_? is raw { #`(Block|170303864) ... }# but
> this?
>
>

Re: Is this a bug?

[Elizabeth Mattijsen]

I think you want:

  .say for reverse lines;

not sure what you are trying to achieve otherwise, but:

   say { }

producing something like

   -> ;; $_? is raw { #`(Block|170303864) … }

feels entirely correct to me.   :-)


Liz

> On 18 Sep 2016, at 21:52, Parrot Raiser <1parr...@gmail.com> wrote:
> 
> This code:
> 1 #! /home/guru/bin/perl6
> 2
> 3 # Ask for some lines and output them in reverse
> 4 # Work out the appropriate EOF symbol for the OS
> 5
> 6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D");
> 7
> 8 say "Please enter some lines and end them with $EOF";
> 9
> 10 say { for reverse lines() {} };
> 11
> 12 # End
> produces this:
> Please enter some lines and end them with CTRL-D# obviously from line 8
> -> ;; $_? is raw { #`(Block|170303864) ... }# but this?

Is this a bug?

[Parrot Raiser]

This code:
1 #! /home/guru/bin/perl6
2
3 # Ask for some lines and output them in reverse
4 # Work out the appropriate EOF symbol for the OS
5
6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D");
7
8 say "Please enter some lines and end them with $EOF";
9
10 say { for reverse lines() {} };
11
12 # End
produces this:
Please enter some lines and end them with CTRL-D# obviously from line 8
-> ;; $_? is raw { #`(Block|170303864) ... }# but this?

[perl6/specs] 2d1c74: fixed my own bug s/=dATA/=data/

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 2d1c745b50b9da6ee11151e6e2f7d71e2e7c6f3d
  
https://github.com/perl6/specs/commit/2d1c745b50b9da6ee11151e6e2f7d71e2e7c6f3d
  Author: Herbert Breunung lichtk...@cpan.org
  Date:   2012-04-04 (Wed, 04 Apr 2012)

  Changed paths:
M S28-special-names.pod

  Log Message:
  ---
  fixed my own bug s/=dATA/=data/

Re: Bug?

[Moritz Lenz]

On 07/14/2011 11:47 PM, Parrot Raiser wrote:
 When a subroutine is invoked with an empty parameter list, as follows:
 
 run_stuff();
 
 sub run_stuff {
 my ($parm) = @_;
 say Parameter is $parm;
 }
 
 @_[0] contains Any().

Not Any(), but Any (which say() prints as Any() to ease debugging)

 Should it?

Yes.

Re: Bug?

[Patrick R. Michaud]

On Sun, Jul 17, 2011 at 10:40:01AM +0200, Moritz Lenz wrote:
 On 07/14/2011 11:47 PM, Parrot Raiser wrote:
  When a subroutine is invoked with an empty parameter list, as follows:
  
  run_stuff();
  
  sub run_stuff {
  my ($parm) = @_;
  say Parameter is $parm;
  }
  
  @_[0] contains Any().
 
 Not Any(), but Any (which say() prints as Any() to ease debugging)
 
  Should it?
 
 Yes.

Not exactly -- master gets this wrong.  Type objects are supposed
to stringify to  and produce a warning.

Nom (cf0da7d) also gets this somewhat wrong at present (but still better 
than master); it's treating the assignment as an item assignment.

Pm

Re: Bug?

[Bruce Gray]

On Jul 14, 2011, at 4:47 PM, Parrot Raiser wrote:


When a subroutine is invoked with an empty parameter list, as follows:

run_stuff();

sub run_stuff {
  my ($parm) = @_;
  say Parameter is $parm;
}

@_[0] contains Any().

Should it?


Yes, but only because of the way you are inspecting it.

When run_stuff is called with no arguments, @_ is empty.
It does *not* contain an element with the value Any; it contains no  
elements at all.


When you ask for the value of a specific (and non-existent) element of  
the array,

you only see that the element has no defined value yet.
(The `Any` value in Perl 6 is like the `undef` value in Perl 5.)
The same will happen if you declared @foo, then asked for the value of  
@foo[42].



perl -MData::Dumper -e 'sub look { print Dumper scalar(@_), \@_,  
$_[0]; } look();'

   $VAR1 = 0;
   $VAR2 = [];
   $VAR3 = undef;
perl6 -e 'sub look { .say for @_.elems, @_.perl, @_[0].perl; }; look();'
   0
   []
   Any

--
Hope this helps,
Bruce Gray (Util)

Bug?

[Parrot Raiser]

When a subroutine is invoked with an empty parameter list, as follows:

run_stuff();

sub run_stuff {
my ($parm) = @_;
say Parameter is $parm;
}

@_[0] contains Any().

Should it?

[perl #81548] [BUG] Can't do 'handles' on a type in Rakudo

[Moritz Lenz via RT]

FWIW 'has $!a handles TypeObject' is now implemented, and works fine for
roles.

It doesn't work for classes, because they have a .new method. So the
standard .new is overridden, trying to call the .new on an attribute,
but since there's no instance yet, the access to the attribute fails.

That's a conceptual problem and needs a spec resolution.

One possible approach would be to only install methods not yet present
in $?CLASS or its superclassess any better ideas?

Moritz

Re: [perl #76442] [BUG} say ?1..2 # prints ones indefinitively

[Carl Mäsak]

cognominal stef ():
 Currently the Range creator method does not coerce its parameters.
 I think Range should be a role so as to impose some constraint.
 I think  Bool..2  should fail.

For what it's worth, I disagree. I think Bool..2 should be equivalent
to 0..2 (since Bool is a type object, which numifies to 0). Possibly
with a warning, since something undefined is being numified.

Patrick pointed out on #perl6 that infix:.. cannot be meant to
numify by default, because then 'a'..'z' wouldn't work. But either of
these options would still be viable:

* If the rhs is Numeric, numify the lhs.
* If either the lhs or the rhs is Numeric, numify the other one.

I haven't come up with a use case to show that one of these options is
better than the other. The first is a bit reminiscent of
smartmatching; the second is more symmetric.

I don't think Range should be a role. I don't have any rational
argument, just the feeling that it's something of a premature type
restriction.

// Carl

[perl #72972] [BUG] False ~~ True in Rakudo

[Moritz Lenz via RT]

On Sat Feb 20 13:31:33 2010, masak wrote:
 spinclad rakudo: say False ~~ True
 p6eval rakudo ec47f3: OUTPUT«1␤»
 masak o.O
 spinclad (which is Worng)
 colomon alpha: say False ~~ True
 p6eval alpha 30e0ed: OUTPUT«1␤»
 lue pugs: say False ~~ True
 p6eval pugs: OUTPUT«␤»
 * masak submits rakudobug
 masak can't believe no-one caught this before.

No one caught this so far, because it's according to the spec. Read
http://perlcabal.org/syn/S03.html#Smart_matching :-)

Afaict this was the case so that

given $thing {
   ...
   when True { # always matches }
}

But we might wish to change that, and use

  when *

As the always matching alternative.

At least I'd find it more intuitive if smart-matching against Bool would
coerce the the LHS to Bool and then do a comparison, much like
smart-matching against strings and numbers work.

The downside is that then

given $thing {
when some_function($_) { ... }
}

won't work as intuitively expected if $thing is false and some_function
returns True.

But IMHO this is not what smartmatching and given/when is meant for (at
least not primarily), so we could sacrifice this possible usage. But I
won't do so without permission from Larry.

Cheers,
Moritz

Re: [perl #72972] [BUG] False ~~ True in Rakudo

[David Green]

On 2010-Feb-22, at 2:08 am, Moritz Lenz wrote:
At least I'd find it more intuitive if smart-matching against Bool  
would coerce the the LHS to Bool and then do a comparison, much like  
smart-matching against strings and numbers work.


The downside is that then: given $thing { when some_function($_)  
{...} }
won't work as intuitively expected if $thing is false and  
some_function

returns True.



The problem is the same construct is trying to do two different  
things.  I agree that Any ~~ Bool should compare both sides as bool,  
because that's more consistent, and there should be another way to  
ignore the LHS.


I propose whenever: it suggests that any time whatsoever that the  
RHS is true, the block will be executed.  It's like when, because it  
is related, but it also has the hand-waving, dismissive feeling of  
whatever, as in, Given $foo?  Whatever!!  I'm ignoring that and  
looking only at this particular value now!



  say Q: $question (Y/N)?;
  my Bool $answer = %answers{$question};
  my Bool $guess = get-response;

  given $guess
  {
  whenever now()  $limit  { say Time's up! }
  when $answer  { say That is correct! }
  default  { say Sorry, wrong answer }
  }



-David

Re: [perl #72914] [BUG] Rakudo doesn't treat ^$n at the end of an infix:... right

[Mark J. Reed]

On Wed, Feb 17, 2010 at 7:32 PM, Carl Mäsak
perl6-bugs-follo...@perl.org wrote:
  my @a = (4...^5); say @a.perl # should be 4 3 2 1 0 1 2 3 4, according to 
 TimToady


That's 4 ... ^5, right?  If so, I don't see how you get that.  I'd
expect (4,0,1,2,3,4), without the countdown between 4 and 0.


-- 
Mark J. Reed markjr...@gmail.com

Re: [perl #72914] [BUG] Rakudo doesn't treat ^$n at the end of an infix:... right

[Larry Wall]

On Thu, Feb 18, 2010 at 12:45:23PM -0500, Mark J. Reed wrote:
: On Wed, Feb 17, 2010 at 7:32 PM, Carl Mäsak
: perl6-bugs-follo...@perl.org wrote:
:   my @a = (4...^5); say @a.perl # should be 4 3 2 1 0 1 2 3 4, according to 
TimToady
: 
: 
: That's 4 ... ^5, right?  If so, I don't see how you get that.  I'd
: expect (4,0,1,2,3,4), without the countdown between 4 and 0.

Unlike the .. operator, the ... operator does autoreversing.  Also, it's
a list infix operator, which means it takes a list on either side.
Since ^5 can produce a list, what ... sees is, in the abstract:

4 ... 0, 1, 2, 3, 4

In reality, the right list is lazy, so ... has to .get the first value
from the iterator on the RHS and examine what it gets back.  If that
is a limit value, it tells ... how far and in what direction to keep
going with the left side.  So effectively the ... above really only
needs to know

4 ... 0

before it decides how to proceed.

Sometimes the ... has to pull two values off the RHS.  If the first
value is a * or a closure, then the first argument says how to derive
new values on the left, and the 2nd value on the right gives the limit.
To be clearer, or at least different, the programmer could write:

4, 3 ... *, ^5

This question arises, of course, because ... doesn't currently support a ...^
notation as ..^ provides for ranges, so 0...^5 doesn't do what you might
expect.  We might well fix that, or at least detect it and warn.  But it
does seem a bit odd to have to put your own epsilon:

0 ... *, 5-훜

so maybe

0 ...^ *, 5

could be forced to mean that.  Might be an argument for moving the
increment to the other side:

0, *+1 ...^ 5

We'd have to think about the ramifications of that though, which are not
all pretty.  In particular, we still need the * on the right for

1,2,4 ... *

since a missing term:

1,2,4,* ...

would be bad to parse, since we wouldn't know whether to expect a term
or an infix.  Maybe, though, that's confusing two different uses of *,
since this makes perfect sense:

1,2,4,* ... *

and admits things like

1,1,[+] ... *  # fib

And if we see

1,2,4 ... *

we can assume it means

1,2,4,* ... *

Likewise

1,2,4 ... 256

would really mean

1,2,4,* ... 256

Maybe I like it.

Larry

Re: [perl #71536] [BUG] Rakudo allows two multi variants with the exact same signature to be defined

[Jonathan Worthington]

On 22/12/2009 10:22, Moritz Lenz wrote:

Carl MXXsak (via RT) wrote:
   

This be Rakudo 8dc189.

$ perl6 -e 'multi sub f($a) {}; multi sub f($a) {}; f(42)'
Ambiguous dispatch to multi 'f'. Ambiguous candidates had signatures:
:(Any $a)
:(Any $a)

The definition of two variants with equivalent signatures (i.e.
identical up to names) can, and IMHO should, be caught statically.
 

I've wondered about that too, and for multi methods it can make sense to
have two multis with the same signature, for example for usage with .+
and .*

Is there a way to call multiple multi subs?

   
.+ and .* will call all multi candidates as well as all the way up the 
hierarchy. I actually have written code that takes advantage of being 
able to do this - it's a cute way to handle simple pub/sub stuff.



Unless/until there is some excellent introspection into where clauses,
there are limits to the signature comparison that can be made, but at
least the simple cases should be no problem.
 

agreed.

   

Aye; the general problem is turing complete.

Jonathan

MMD bug or what?

[Илья]

Hi there,
I `m looking into MMD, example:

 multi t (@a) {1}
 multi t (Array $a) {2}
 multi t (Positional $a) {3}
 multi t (Positional[Array] $a) {4}

 say t(a b c)
1
 say t(Array.new)
2
 my $foo does Positional; say t($foo)
1
 my @a; say t(@a)
2

I am expected some sort of ambiguous there.

Thank you!

Ihrd

Re: Not a bug?

[Carl Mäsak]

Ovid ():
  $ perl6 -e 'my $foo = foo;say { ~ $foo ~ }'
   ~ foo ~

Easy solution: only use double quotes when you want to interpolate. :)

This is not really an option when running 'perl6 -e' under bash, though.

// Carl

Re: Not a bug?

[Jon Lang]

On Mon, Jan 12, 2009 at 2:15 AM, Carl Mäsak cma...@gmail.com wrote:
 Ovid ():
  $ perl6 -e 'my $foo = foo;say { ~ $foo ~ }'
   ~ foo ~

 Easy solution: only use double quotes when you want to interpolate. :)

 This is not really an option when running 'perl6 -e' under bash, though.

$ perl6 -e 'my $foo = foo;say q:qq({ ~ $foo ~ })'

...or something to that effect.

-- 
Jonathan Dataweaver Lang

Re: Not a bug?

[Tim Bunce]

On Sun, Jan 11, 2009 at 04:41:12PM -0800, Ovid wrote:
 I really don't think this is a bug, but it did confuse the heck out of me at 
 first.  This *is* expected behavior due to how {} is interpolated in strings, 
 yes?
 
   $ perl6 -e 'my $foo = foo;say  ~ $foo ~ '
   foo
   $ perl6 -e 'my $foo = foo;say { ~ $foo ~ }'
~ foo ~ 

I presume string interpolation is, er, set-up, at compile-time.
So it only happened here because { ~ $foo ~ } was rewritten to
{$foo} at compile-time.  And if { and } were replaced with
variables, for example, then the interpolation wouldn't have happened.
Right?

Tim.

Re: Not a bug?

[Larry Wall]

On Mon, Jan 12, 2009 at 03:43:47AM -0800, Jon Lang wrote:
: On Mon, Jan 12, 2009 at 2:15 AM, Carl Mäsak cma...@gmail.com wrote:
:  Ovid ():
:   $ perl6 -e 'my $foo = foo;say { ~ $foo ~ }'
:~ foo ~
: 
:  Easy solution: only use double quotes when you want to interpolate. :)
: 
:  This is not really an option when running 'perl6 -e' under bash, though.
: 
: $ perl6 -e 'my $foo = foo;say q:qq({ ~ $foo ~ })'
: 
: ...or something to that effect.

Assuming that's what was wanted.  I figgered they want something more
like:

$ perl6 -e 'my $foo = foo; say q[{] ~ $foo ~ q[}];'

Larry

Re: Not a bug?

[Jon Lang]

On Mon, Jan 12, 2009 at 1:08 PM, Larry Wall la...@wall.org wrote:
 On Mon, Jan 12, 2009 at 03:43:47AM -0800, Jon Lang wrote:
 : On Mon, Jan 12, 2009 at 2:15 AM, Carl Mäsak cma...@gmail.com wrote:
 :  Ovid ():
 :   $ perl6 -e 'my $foo = foo;say { ~ $foo ~ }'
 :~ foo ~
 : 
 :  Easy solution: only use double quotes when you want to interpolate. :)
 : 
 :  This is not really an option when running 'perl6 -e' under bash, though.
 :
 : $ perl6 -e 'my $foo = foo;say q:qq({ ~ $foo ~ })'
 :
 : ...or something to that effect.

 Assuming that's what was wanted.  I figgered they want something more
 like:

$ perl6 -e 'my $foo = foo; say q[{] ~ $foo ~ q[}];'

True enough.  Either one of these would be more clear than the
original example in terms of user intent.

As well, isn't there a way to escape a character that would otherwise
be interpolated?  If the intent were as you suppose, the original
could be rewritten as:

  $ perl6 -e 'my $foo = foo;say \{ ~ $foo ~ }'

(Or would you need to escape the closing curly brace as well as the
opening one?)

-- 
Jonathan Dataweaver Lang

Re: Not a bug?

[Larry Wall]

On Mon, Jan 12, 2009 at 01:19:12PM -0800, Jon Lang wrote:
: As well, isn't there a way to escape a character that would otherwise
: be interpolated?  If the intent were as you suppose, the original
: could be rewritten as:
: 
:   $ perl6 -e 'my $foo = foo;say \{ ~ $foo ~ }'

Sure, though in any case I'd probably prefer:

$ perl6 -e 'my $foo = foo; say Qs/{$foo}/'

: (Or would you need to escape the closing curly brace as well as the
: opening one?)

Not unless something outside of it all was attempting to count braces.
But the P6 parser has sworn off all such activities for P6-derived
code.  Parsing something first as a string and then again as some
other language is generally looked upon as a Bad Plan these days.

Which is, of course, why { is a problem now.  Perhaps use of nested
double quotes deserves a warning.

Larry

Re: Not a bug?

[jason switzer]

On Mon, Jan 12, 2009 at 3:54 PM, Larry Wall la...@wall.org wrote:

 On Mon, Jan 12, 2009 at 01:19:12PM -0800, Jon Lang wrote:
 : As well, isn't there a way to escape a character that would otherwise
 : be interpolated?  If the intent were as you suppose, the original
 : could be rewritten as:
 :
 :   $ perl6 -e 'my $foo = foo;say \{ ~ $foo ~ }'

 Sure, though in any case I'd probably prefer:

$ perl6 -e 'my $foo = foo; say Qs/{$foo}/'

 : (Or would you need to escape the closing curly brace as well as the
 : opening one?)

 Not unless something outside of it all was attempting to count braces.
 But the P6 parser has sworn off all such activities for P6-derived
 code.  Parsing something first as a string and then again as some
 other language is generally looked upon as a Bad Plan these days.

 Which is, of course, why { is a problem now.  Perhaps use of nested
 double quotes deserves a warning.


masak++ was right, if you use single quotes it works properly. Here's how
you do it from a bash prompt:

$ ./perl6 -e 'my $foo = '\''foo'\''; say '\''{'\'' ~ $foo ~ '\''}'\'' '
{foo}

Notice the overly redundant single-quotes; in fact, all of those quotes are
single quotes.

-Jason s1n Switzer

Not a bug?

[Ovid]

I really don't think this is a bug, but it did confuse the heck out of me at 
first.  This *is* expected behavior due to how {} is interpolated in strings, 
yes?

  $ perl6 -e 'my $foo = foo;say  ~ $foo ~ '
  foo
  $ perl6 -e 'my $foo = foo;say { ~ $foo ~ }'
   ~ foo ~ 

 
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Re: Not a bug?

[Larry Wall]

On Sun, Jan 11, 2009 at 04:41:12PM -0800, Ovid wrote:
: I really don't think this is a bug, but it did confuse the heck out of me at 
first.  This *is* expected behavior due to how {} is interpolated in strings, 
yes?
: 
:   $ perl6 -e 'my $foo = foo;say  ~ $foo ~ '
:   foo
:   $ perl6 -e 'my $foo = foo;say { ~ $foo ~ }'
:~ foo ~ 

Yep, that's working right.  Or at least, working as designed...  :)

Larry

Re: Bug or feature? Hash autovivification

[Patrick R. Michaud]

On Wed, Dec 31, 2008 at 08:06:48AM -0800, Ovid wrote:
 Just stumbled across this, but I can't tell from S09 if this is a bug or 
 feature:
 
   $ ./perl6 -e 'my %foo; if %fooa {}; say %foo.perl'
   {a = undef}

It's a bug.  In order to simplify the slicing implementation
Rakudo currently autovivifies elements on read access.  This
will be fixed again very soon -- I just want to get the other
variable refactors for Rakudo worked out first.

Pm

Bug or feature? Hash autovivification

[Ovid]

Just stumbled across this, but I can't tell from S09 if this is a bug or 
feature:

  $ ./perl6 -e 'my %foo; if %fooa {}; say %foo.perl'
  {a = undef}

 
I wasn't expecting auto-vivification there.  The examples in S09 use HoH 
instead of a flat hash:

But these bindings do autovivify:

   my %hash;
   my $val := %hashfoobar;

   my @array;
   my $cap = \...@array[0][0]; # $cap is a Capture object ‐ see S02
   my :($obj) := $cap;   # @array[0][0] created here

   my @array;
   foo(@array[0][0]);
   sub foo ($obj is rw) {...}  # same thing, basically

   my %hash;
   %hashfoobar = foo; # duh

So is this a bug?

Revision: 34706

$ uname -a
Darwin curtis-poes-computer-3.local 9.5.1 Darwin Kernel Version 9.5.1: Fri Sep 
19 16:19:24 PDT 2008; root:xnu-1228.8.30~1/RELEASE_I386 i386

Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Re: Bug or feature? Hash autovivification

[Larry Wall]

On Wed, Dec 31, 2008 at 08:06:48AM -0800, Ovid wrote:
: Just stumbled across this, but I can't tell from S09 if this is a bug or 
feature:
: 
:   $ ./perl6 -e 'my %foo; if %fooa {}; say %foo.perl'
:   {a = undef}

Definitely bug.  Rvalues aren't supposed to autovivify.

Larry

Re: [perl #60828] [BUG] [EMAIL PROTECTED] returns ridicously long lists

[Moritz Lenz]

Patrick R. Michaud wrote:
 Currently Rakudo is treating [EMAIL PROTECTED] as though it's
 prefix:^ on a List, which S03 says 
 
 If [prefix:^ is] applied to a list, it generates a
 multidimensional set of subscripts.
 
 for ^(3,3) { ... } # (0,0)(0,1)(0,2)(1,0)(1,1)(1,2)(2,0)(2,1)(2,2)
 
 So, Rakudo is currently seeing [EMAIL PROTECTED] as following this definition,
 and trying to generate the subscripts (perhaps wrongly).

Yes, wrongly:
08:48  moritz_ rakudo: say (^(3,3)).perl
08:48  p6eval rakudo 33212: OUTPUT[[0, 1, 2, 0, 1, 2]␤]
08:51  moritz_ rakudo: say (^(10,3)).perl
08:51  p6eval rakudo 33212: OUTPUT[[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2]␤]

It counts up first the first index, then the second.


I see how the specced makes sense for a List of Ints, but not for any
other list - any ideas from the design team?

Moritz

 There's still some ambiguity in how (or if) we should support
 both interpretations [1], so we'll want to get that resolved before
 we can fix prefix:^ here.

 [1]  http://irclog.perlgeek.de/perl6/2008-11-26#i_720703

Re: [perl #60828] [BUG] [EMAIL PROTECTED] returns ridicously long lists

[Larry Wall]

On Wed, Nov 26, 2008 at 08:54:50AM +0100, Moritz Lenz wrote:
: 
: 
: Patrick R. Michaud wrote:
:  Currently Rakudo is treating [EMAIL PROTECTED] as though it's
:  prefix:^ on a List, which S03 says 
:  
:  If [prefix:^ is] applied to a list, it generates a
:  multidimensional set of subscripts.
:  
:  for ^(3,3) { ... } # (0,0)(0,1)(0,2)(1,0)(1,1)(1,2)(2,0)(2,1)(2,2)
:  
:  So, Rakudo is currently seeing [EMAIL PROTECTED] as following this 
definition,
:  and trying to generate the subscripts (perhaps wrongly).
: 
: Yes, wrongly:
: 08:48  moritz_ rakudo: say (^(3,3)).perl
: 08:48  p6eval rakudo 33212: OUTPUT[[0, 1, 2, 0, 1, 2]␤]
: 08:51  moritz_ rakudo: say (^(10,3)).perl
: 08:51  p6eval rakudo 33212: OUTPUT[[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
: 1, 2]␤]
: 
: It counts up first the first index, then the second.
: 
: 
: I see how the specced makes sense for a List of Ints, but not for any
: other list - any ideas from the design team?

My guess is that the list overloading will simply vanish into thin air,
and you'll have to say something like

^«(3,3)

to get the current Parrot meaning, and

[X] ^«(3,3)

or

^3 X ^3

to get the specced list meaning.  But other viewpoints are welcome...

Larry

Re: [perl #60828] [BUG] [EMAIL PROTECTED] returns ridicously long lists

[Patrick R. Michaud]

On Wed, Nov 26, 2008 at 06:21:22PM -0800, Larry Wall wrote:
 On Wed, Nov 26, 2008 at 08:54:50AM +0100, Moritz Lenz wrote:
 : Patrick R. Michaud wrote:
 :  Currently Rakudo is treating [EMAIL PROTECTED] as though it's
 :  prefix:^ on a List, which S03 says 
 :  for ^(3,3) { ... } # (0,0)(0,1)(0,2)(1,0)(1,1)(1,2)(2,0)(2,1)(2,2)
 : 
 : I see how the specced makes sense for a List of Ints, but not for any
 : other list - any ideas from the design team?
 
 My guess is that the list overloading will simply vanish into thin air,
 and you'll have to say something like
 
 ^«(3,3)
 
 to get the current Parrot meaning, and
 
 [X] ^«(3,3)
 
 or
 
 ^3 X ^3
 
 to get the specced list meaning.  But other viewpoints are welcome...

+1 to the idea that [EMAIL PROTECTED] is the same as [EMAIL PROTECTED] .  Now 
implemented
as such in Rakudo, and unfudged the corresponding tests.

Closing ticket -- thanks!

Pm

Rakudo bug reports still go to [EMAIL PROTECTED]

[Patrick R. Michaud]

Some of you may have seen the announcements on the Parrot
lists that Parrot will be starting to use trac.parrot.org 
for its issue tracking and bug reporting system.

This is just a note that Rakudo's bug reports will continue
to be hosted on the rt.perl.org server, and we will continue
to use [EMAIL PROTECTED] for submitting new issues and
bug reports.

In addition, sometime before the February 2009 release we
expect to move the Rakudo sources out of the Parrot repository
and into a separate location at svn.perl.org.  More details
on this as we get closer to doing so.

Thanks!

Pm

Re: [perl #58302] [BUG] binary junctions of undefs in boolean context fails (21/37)

[Moritz Lenz]

Patrick R. Michaud wrote:
 On Mon, Aug 25, 2008 at 12:15:05AM +0200, Moritz Lenz wrote:
 Larry Wall wrote:
  I think it would be best if all boolean contexts collapse consistently,
  and I would consider all of those to be boolean contexts.  More
  precisely,  and || are boolean on the left, but not on the right.
 
 Very good.
 As a follow-up for the testers: should ok() expect an Object as its
 first argument? If so we could say
 
 ok 1|2, 'Junction 1|2 is true in boolean context';
 
 Keeping with my general philosophy that I'd like to keep
 the requirements needed to run Test.pm (and the test suite)
 as simple as possible, I'd prefer to not require type checking
 within Test.pm in order for it to work right.

 Beyond that, if we're testing a Junction in boolean
 context, I think I would prefer to make that an explicit
 part of the test itself:
 
 ok ?(1|2), 'Junction 1|2 is true in boolean context';

I re-wrote the tests to use that kind of syntax, and add it to the
official tests:
http://svn.pugscode.org/pugs/t/spec/S03-junctions/boolean-context.t

My next step will be to fudge it for rakudo.

Cheers,
Moritz


-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Re: [perl #58302] [BUG] binary junctions of undefs in boolean context fails (21/37)

[Moritz Lenz]

Moritz Lenz wrote:
 Tests 34 to 36 were a bit overcritical:
 
 (0|undef  say not ok 34) || say not ok 34;
 (0undef  say not ok 35) || say not ok 35;
 (0^undef  say not ok 36) || say not ok 36;
 
 but are easily corrected. The rest seem fine to me.

Easier said than done.
Question to p6l: do  and || autothread? Or do they collapse the
junction prior to evaluation? (I hope the latter, since I think it's
more dwimmy).

Also do prefix:? and prefix:! collapse the junction?

Cheers,
Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Re: [perl #58302] [BUG] binary junctions of undefs in boolean context fails (21/37)

[Larry Wall]

On Sun, Aug 24, 2008 at 09:22:25PM +0200, Moritz Lenz wrote:
: Moritz Lenz wrote:
:  Tests 34 to 36 were a bit overcritical:
:  
:  (0|undef  say not ok 34) || say not ok 34;
:  (0undef  say not ok 35) || say not ok 35;
:  (0^undef  say not ok 36) || say not ok 36;
:  
:  but are easily corrected. The rest seem fine to me.
: 
: Easier said than done.
: Question to p6l: do  and || autothread? Or do they collapse the
: junction prior to evaluation? (I hope the latter, since I think it's
: more dwimmy).
: 
: Also do prefix:? and prefix:! collapse the junction?

I think it would be best if all boolean contexts collapse consistently,
and I would consider all of those to be boolean contexts.  More
precisely,  and || are boolean on the left, but not on the right.

Interestingly, ? and ?| collapse both sides because they coerce both
sides to boolean.  Either that, or we make neither side collapse,
if someone can come up with a use case for junctional booleans,
though I suspect the same purpose can be served by + and +| if you're
careful only to feed it 1 or 0.  So probably conceptual consistency
is better here.

Larry

Re: [perl #58302] [BUG] binary junctions of undefs in boolean context fails (21/37)

[Patrick R. Michaud]

On Sun, Aug 24, 2008 at 03:00:54PM -0700, Larry Wall wrote:
 : Question to p6l: do  and || autothread? Or do they collapse the
 : junction prior to evaluation? (I hope the latter, since I think it's
 : more dwimmy).
 : 
 : Also do prefix:? and prefix:! collapse the junction?
 
 I think it would be best if all boolean contexts collapse consistently,
 and I would consider all of those to be boolean contexts.  More
 precisely,  and || are boolean on the left, but not on the right.

Yay!  

I'm assuming the same holds true for the conditional expression
in C?? !!.

Thanks,

Pm

Re: [perl #58302] [BUG] binary junctions of undefs in boolean context fails (21/37)

[Moritz Lenz]

Larry Wall wrote:
 On Sun, Aug 24, 2008 at 09:22:25PM +0200, Moritz Lenz wrote:
 : Moritz Lenz wrote:
 :  Tests 34 to 36 were a bit overcritical:
 :  
 :  (0|undef  say not ok 34) || say not ok 34;
 :  (0undef  say not ok 35) || say not ok 35;
 :  (0^undef  say not ok 36) || say not ok 36;
 :  
 :  but are easily corrected. The rest seem fine to me.
 : 
 : Easier said than done.
 : Question to p6l: do  and || autothread? Or do they collapse the
 : junction prior to evaluation? (I hope the latter, since I think it's
 : more dwimmy).
 : 
 : Also do prefix:? and prefix:! collapse the junction?
 
 I think it would be best if all boolean contexts collapse consistently,
 and I would consider all of those to be boolean contexts.  More
 precisely,  and || are boolean on the left, but not on the right.

Very good.
As a follow-up for the testers: should ok() expect an Object as its
first argument? If so we could say

ok 1|2, 'Junction 1|2 is true in boolean context';

(Which has the nice side effect of not confusing fudge because more
tests are executed than expected).

Moritz


-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Re: [perl #58302] [BUG] binary junctions of undefs in boolean context fails (21/37)

[Larry Wall]

On Sun, Aug 24, 2008 at 05:05:46PM -0500, Patrick R. Michaud wrote:
: On Sun, Aug 24, 2008 at 03:00:54PM -0700, Larry Wall wrote:
:  : Question to p6l: do  and || autothread? Or do they collapse the
:  : junction prior to evaluation? (I hope the latter, since I think it's
:  : more dwimmy).
:  : 
:  : Also do prefix:? and prefix:! collapse the junction?
:  
:  I think it would be best if all boolean contexts collapse consistently,
:  and I would consider all of those to be boolean contexts.  More
:  precisely,  and || are boolean on the left, but not on the right.
: 
: Yay!  
: 
: I'm assuming the same holds true for the conditional expression
: in C?? !!.

Indeed.

Larry

Re: [perl #58302] [BUG] binary junctions of undefs in boolean context fails (21/37)

[Patrick R. Michaud]

On Mon, Aug 25, 2008 at 12:15:05AM +0200, Moritz Lenz wrote:
 Larry Wall wrote:
  I think it would be best if all boolean contexts collapse consistently,
  and I would consider all of those to be boolean contexts.  More
  precisely,  and || are boolean on the left, but not on the right.
 
 Very good.
 As a follow-up for the testers: should ok() expect an Object as its
 first argument? If so we could say
 
 ok 1|2, 'Junction 1|2 is true in boolean context';

Keeping with my general philosophy that I'd like to keep
the requirements needed to run Test.pm (and the test suite)
as simple as possible, I'd prefer to not require type checking
within Test.pm in order for it to work right.

Beyond that, if we're testing a Junction in boolean
context, I think I would prefer to make that an explicit
part of the test itself:

ok ?(1|2), 'Junction 1|2 is true in boolean context';

Pm

Re: .perl, nested arrays, parens and a bug with .perl after hyperop

[Audrey Tang]

在 May 21, 2007 8:45 AM 時，Juerd Waalboer 寫到：


Steffen Schwigon skribis 2007-05-21  1:28 (+0200):
That's ARRAY := ARRAY there, so the following should dwym:

my @foo := [ 1, 2, 3 ];

However, this does not work with pugs, so I don't know if I am  
wrong, or

pugs is wrong.




Pugs is wrong and will be corrected before 6.28.0. :-)

Audrey

.perl, nested arrays, parens and a bug with .perl after hyperop

[Steffen Schwigon]

Hi!

Yesterday we discussed a strange behaviour of .perl on the result of a
hyperoperator. The basic bug is that

  my @hyp = -« ([1, 2], 3);
  say @hyp.perl;

outputs

  [(-1, -2), -3]

which are strange inner parens inside the brackets that would get
flattened after eval. I committed a :todo test for this in
t/builtins/{perl,perl2}.t.

Some questions arose during the discussion:

1. Should assigning an arrayref to an array dereference? Eg., so that

 @foo = [[1, 2], 3]

   is basically the same as

 @foo = ([1, 2], 3)

   Currently the first assignment generates a list whose first element
   is the complete array reference:

 [[[1, 2], 3],]

   which isn't maybe the expected behaviour. Or is it? Which Synopses
   describes this?


2. Shouldn't .perl generally use parens for outputting arrays (at
   least on the most outer level)? Because currently eval'ing the
   output contains the problem from question 1.


3. Which test file is the real one:

 pugs/t/builtins/perl.t
   or
 pugs/t/builtins/perl2.t ?

   They are similar but not identical.


(Greeti+Tha)nX
Steffen 
-- 
Steffen Schwigon http://renormalist.net
Dresden Perl Mongers http://dresden-pm.org/
Deutscher Perl-Workshop http://www.perl-workshop.de/

Re: Junctions as arguments (Pugs bug)

[Jonathan Rockway]

Ovid wrote:
(reversed the message a bit)
   is 'b', any('a' .. 'h'), 'junctions should work';

This looks like a Test bug; it's doing something like:

   is 'b', 'a' # not ok
   is 'b', 'b' # ok
   is 'b', 'c' # not ok
   ...

If you write:

   ok 'b' === any('a'..'h')

The result is one passing test.


 That outputs something like the following on my system (Version: 6.2.13
 (r14927))

   any(VInt 1,VInt 2,VInt 3,VInt 4)
   any(VRef Scalar:0x2aa80e0)

My question is, what is the expected output of say-ing a junction?
Should say (1|2|3) randomly print 1, 2, or 3?  Should say (123)
say 1, then say 2, then say 3?

I can understand it going either way (although I'd lean towards what
Ovid is expecting), but it would be good to hear what others think
before tests are committed.


-- 
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;

Re: Junctions as arguments (Pugs bug)

[Larry Wall]

On Wed, Dec 20, 2006 at 10:26:41AM -0600, Jonathan Rockway wrote:
: Ovid wrote:
: (reversed the message a bit)
:is 'b', any('a' .. 'h'), 'junctions should work';
: 
: This looks like a Test bug; it's doing something like:
: 
:is 'b', 'a' # not ok
:is 'b', 'b' # ok
:is 'b', 'c' # not ok
:...
: 
: If you write:
: 
:ok 'b' === any('a'..'h')
: 
: The result is one passing test.
: 
: 
:  That outputs something like the following on my system (Version: 6.2.13
:  (r14927))
: 
:any(VInt 1,VInt 2,VInt 3,VInt 4)
:any(VRef Scalar:0x2aa80e0)
: 
: My question is, what is the expected output of say-ing a junction?
: Should say (1|2|3) randomly print 1, 2, or 3?  Should say (123)
: say 1, then say 2, then say 3?
: 
: I can understand it going either way (although I'd lean towards what
: Ovid is expecting), but it would be good to hear what others think
: before tests are committed.

What you're seeing is standard autothreading behavior, which is
described in S09, Junctions.  To avoid autothreading, a routine must
declare itself prepared to handle junctions with an appropriate type
signature, and I'm not sure we want to complicate Test to that extent,
since it makes it harder to port.

Larry

Re: S04 default { } bug?

[Larry Wall]

On Mon, Oct 24, 2005 at 07:39:23AM +0300, Ilmari Vacklin wrote:
: Hi,
: 
: S04 says thus:
: 
: The default case:
: 
: default {...}
: 
: is exactly equivalent to
: 
: when true {...}
: 
: However, that parses to:
: 
: if $_ ~~ bool::true { ...; leave }
: 
: Which is not executed if $_ is false, unless ~~ bool::true does
: something special.

It did do something special at the time the Apocalypse was written,
but it was probably a bad idea.  Smart match was going to recognize
obviously boolean expressions and just ignore the other argument.
The problem is that it's not always obvious what's obvious.

Larry

S04 default { } bug?

[Ilmari Vacklin]

Hi,

S04 says thus:

The default case:

default {...}

is exactly equivalent to

when true {...}

However, that parses to:

if $_ ~~ bool::true { ...; leave }

Which is not executed if $_ is false, unless ~~ bool::true does
something special. Perhaps default should be equivalent to:

when $_ { ... }

That is, $_ is always $_, so the block is always executed.

(It also strikes me that using booleans in when clauses could/should be
disallowed entirely.)

-- 
Ilmari Vacklin
(wolverian)

Re: Pugs Bug

[wolverian]

(Replying to p6l instead of p6c as requested.)

On Mon, Apr 04, 2005 at 10:39:16AM -0700, Larry Wall wrote:
 (Now that builtins are just functions out in * space, we can probably
 afford to throw a few more convenience functions out there for common
 operations like word splitting and whitespace trimming.  (Specific
 proposals to p6l please.))

Shouldn't these be just methods? 

 Larry

-- 
wolverian


signature.asc
Description: Digital signature

Re: Pugs Bug

[Adriano Ferreira]

 Shouldn't these be just methods?

I guess not. This is Perl and OO is not mandatory, or even desirable
all the time.

Adriano.

Re: Pugs Bug

[Larry Wall]

On Tue, Apr 05, 2005 at 09:36:18AM +0300, wolverian wrote:
: (Replying to p6l instead of p6c as requested.)
: 
: On Mon, Apr 04, 2005 at 10:39:16AM -0700, Larry Wall wrote:
:  (Now that builtins are just functions out in * space, we can probably
:  afford to throw a few more convenience functions out there for common
:  operations like word splitting and whitespace trimming.  (Specific
:  proposals to p6l please.))
: 
: Shouldn't these be just methods? 

Depends on whether part of the convenience consists of coercing
the argument to a string in the first place.  In all likelihood these
would be multimethods with a single definition, so that if you did
add other definitions of words() or trim(), it would use MMD to try
to figure out which way you probably wanted it coerced.

Plus you really don't want to clutter the Str type with every little
thing you might want to do with a string.  foo.open() will probably
work, but only because it doesn't find a Str.open and fails over to
MMD dispatch, which ends up finding a filehandle constructor.

But suppose words() were a singular multimethod.  If you said

words(@array)

it would call wordsStr, which would (I hope, since arrays know
about string context) coerce @array to a string with ' ' between the
elements, and then split that string into words.  But some people might
prefer that to fail, and force people to use

words([EMAIL PROTECTED])
words(@array)

Maybe there's a pragma that lets you control how much coercion happens.

Larry

Re: Pugs Bug

[wolverian]

On Tue, Apr 05, 2005 at 09:21:41AM -0700, Larry Wall wrote:
 Plus you really don't want to clutter the Str type with every little
 thing you might want to do with a string.  foo.open() will probably
 work, but only because it doesn't find a Str.open and fails over to
 MMD dispatch, which ends up finding a filehandle constructor.

foo.open is just weird. Here I would definitely want at least a
warning, if just for my sanity.

 words(@array)

On the other hand, @array.words seems just as natural as $string.words
to me. I'm not sure how to reconcile this.

Does [EMAIL PROTECTED] DWIM, by the way? I'm not sure about the precedence.

 Maybe there's a pragma that lets you control how much coercion
 happens.

use coercion :oppressively; # They're adverbs, after all!

 Larry

--
wolverian


signature.asc
Description: Digital signature

Re: Pugs Bug

[Juerd]

wolverian skribis 2005-04-05 19:31 (+0300):
 Does [EMAIL PROTECTED] DWIM, by the way? I'm not sure about the precedence.

Yes, . is supertight.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: Pugs Bug

[Larry Wall]

On Tue, Apr 05, 2005 at 07:31:40PM +0300, wolverian wrote:
: Does [EMAIL PROTECTED] DWIM, by the way? I'm not sure about the precedence.

That depends on whether you mean

([EMAIL PROTECTED]).words

or

~(@array.words)

It happens to mean the latter.  A . binds tighter than a symbolic
unary.  In fact, it binds tigher than anything that is not a term,
so that, to the first approximation, a string of things separated by .
can always be thought of as a sort of term with respect to any other
operators.  Standard Perl 6 will never define any precedence levels
between . and term.

Larry

[POST-RELEASE] parrot-0.0.8.1.tgz fixes a slight MANIFEST bug...

[Jeff]

The 'DEVELOPING' file accidentally made its way into the MANIFEST, but
doesn't actually exist in the tarball. It's not a problem, as you can
delete the appropriate line in the MANIFEST and continue, but given the
large file size I thought I should alert you. 0.0.8.1 is being uploaded
at the moment that doesn't have this minor problem.
--
Jeff [EMAIL PROTECTED]