[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:
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
[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: masak 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 masak rakudo: say sign($_) for 42, -42, 0+42i p6eval rakudo 32877: OUTPUT[1-11] masak somehow, that last one doesn't feel right to me. masak I vote for either an error or $x/abs($x) PerlJam why would it be an error? masak because 'sign' could be argued to only be applicable to real numbers. masak i.e. positive numbers, negative numbers, and zero. PerlJam but what is it specced to do? :-) masak ah. masak it's supposed to return the 'sign' of a number. masak i.e. +1, -1 or 0 for the above three groups. masak in that way, it's a bit like =, except it always compares to 0 PerlJam oh, it's wrong anyway I think. PerlJam rakudo: say sign(-5+3i); p6eval rakudo 32877: OUTPUT[1] PerlJam that can't be right. masak it always returns 1 on complex numbers. * masak reports a bug
