[perl #81548] [BUG] Can't do 'handles' on a type in Rakudo
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
[perl #72972] [BUG] False ~~ True in Rakudo
On Sat Feb 20 13:31:33 2010, masak wrote:
> rakudo: say False ~~ True
> rakudo ec47f3: OUTPUT«1»
> o.O
> (which is Worng)
> alpha: say False ~~ True
> alpha 30e0ed: OUTPUT«1»
> pugs: say False ~~ True
> pugs: OUTPUT«»
> * masak submits rakudobug
> 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
[perl #64566] @a[1..*] adds trailing undef value
On Wed Apr 08 14:59:19 2009, moritz wrote:
> 23:55 <@moritz_> rakudo: my @a = 1..4; say @a[1..*].perl
> 23:56 < p6eval> rakudo 6b9755: OUTPUT«[2, 3, 4, undef]»
>
> It should just be [2, 3, 4].
Since the discussion came up on #perl6 if this is really the expected
behaviour, S09 says:
As the end-point of a range, a lone "whatever" means "to the maximum
specified index" (if fixed indices were defined):
say @calendar[5..*]; # Same as: say @calendar[5..11]
say @calendar{Jun..*};# Same as: say @calendar{Jun..Dec}
or "to the largest allocated index" (if there are no fixed indices):
say @data[1..*]; # Same as: say @results[1..5]
It doesn't mention how the postcifcumfix:<[ ]> is supposed to introspect
those to find out if the WhateverCode object constructed by 1..* needs
to receive self.elems or self.elems-1 as an argument.
Which is why I CC: p6l to get some ideas or clarification, and if we
want to maintain this DWIMmy but not very consistent behaviour.
Cheers,
Moritz
[perl #66824] "argument doesn't array" with one-item ranges
On Sun Jun 21 12:05:11 2009, moritz wrote:
> 21:03 <@moritz_> rakudo: my @a = 1, 2, 4; sub f($a) { say $a };
> f(|@a[*-1..*-1])
> 21:03 < p6eval> rakudo 1b06df: OUTPUT«argument doesn't arrayin sub f
> (/tmp/2x4tmnOO68:1)called from Main (/tmp/2x4tmnOO68:2)»
>
I investigated a bit more, and found that @a[*-1..*-1] just gives 4, and
f(|4) results in the same error message. So while the current behaviour
is not very dwimmy, it is at least somewhat understandable.
What's the opinion of the p6l people? Should |@a[1..1] work? even at the
cost of allowing |1 not to be an error?
Cheers,
Moritz
[perl #61130] :nth() does not work with :x() or :g in .subst in Rakudo
On Sun Dec 07 07:24:07 2008, masak wrote:
> The .subst method in Rakudo r33599 can understand :x()...
>
> $ perl6 -e 'say "foo1foo2foo3foo4".subst("foo", "bar", :x(2))' # yes
> bar1bar2foo3foo4
>
> ...and :nth()...
>
> $ perl6 -e 'say "foo1foo2foo3foo4".subst("foo", "bar", :nth(2))' # yes
> foo1bar2foo3foo4
>
> ...and :g...
>
> $ perl6 -e 'say "foo1foo2foo3foo4".subst("foo", "bar", :g)' # yes
> bar1bar2bar3bar4
>
> ...but not :x() together with :nth()...
>
> $ perl6 -e 'say "foo1foo2foo3foo4".subst("foo", "bar", :x(2),
> :nth(2))' # expected foo1bar2foo3bar4
> foo1bar2foo3foo4
>
> ...and not :g together with :nth().
>
> $ perl6 -e 'say "foo1foo2foo3foo4".subst("foo", "bar", :g, :nth(2))' #
> expected foo1bar2foo3bar4
> foo1bar2foo3foo4
>
> The above are my personal expectations. The current version of S05 is
> silent on how :nth() interacts with :x() and :g. There are spectests
> for :g:nth but not (as far as I can see) for :x:nth.
Since your personal expectations are the same as mine, I took the liberty to
turn our expectations into spec tests, in
t/spec/S05-substitution/subst.t (pugs r24207).
The reasoning behind it is quite simple: I imagine :g to mean the same as
:x(*). Now a :x($x) and :nth($n) interact like this:
for 1 .. $x {
match here
if ($x-1) % $n == 0 {
do substitution
}
}
(CC'ing p6l, since it defines language semantics, albeit just a bit)
[perl #60674] sign($x) always returns 1 when $x ~~ Complex
On Wed Nov 19 07:35:48 2008, masak wrote: > what should the behaviour of sign($x) be when $x is complex? I'd argue that it's a Failure. If you care about complex numbers, you usually want an angle instead, which you can get with Complex.polar. (And it's easier to give it a another meaning later that way) (If you wanted a complex number with magnitude one, then you should call that method "phase" or so, but that would confuse most people when talking about real numbers.) Cheers, Moritz > rakudo: say sign($_) for 42, -42, 0+42i > rakudo 32877: OUTPUT[1-11] > somehow, that last one doesn't feel right to me. > I vote for either an error or $x/abs($x) > why would it be an error? > because 'sign' could be argued to only be applicable to real > numbers. > i.e. positive numbers, negative numbers, and zero. > but what is it specced to do? :-) > ah. > it's supposed to return the 'sign' of a number. > i.e. +1, -1 or 0 for the above three groups. > in that way, it's a bit like <=>, except it always compares to > 0 > oh, it's wrong anyway I think. > rakudo: say sign(-5+3i); > rakudo 32877: OUTPUT[1] > that can't be right. > it always returns 1 on complex numbers. > * masak reports a bug
