I solved the (easy) problem 32, implementing gcd($a,$b).
You can check the code in the repository or on the web[1]
But while writing this I noticed that a function written as
sub gcd(Int $a, Int $b)
still accepts float/rational values in input.
I think I read once that a variable of type Int would accept these kind
of assignment but that the value would be coerced to the new type of the
variable, i.e.
my Int $a= 10.1 #=> 10
Could someone explain me what is the expected behaviour?
[1] http://sial.org/pbot/22088
--
blog en: http://www.riffraff.info
blog it: http://riffraff.blogsome.com
jabber : rff.rff at gmail dot com
look the comment:
# Yet, it should be possible to define it even for commutative rings
# other than Integers, so we use a multi sub.
I think that in these examples we should respect the old good
programmin' habits, including the "stay open for extension" idea.
If we'd use a normal sub we would limit all the future user of gcd
(which I expect to be legions ;) to using Int.
<snip>
>> Could someone explain me what is the expected behaviour?
>
> Last time I experimented with this, the type system in Pugs looked
> unfinished. Type constraints were syntactically accepted but worked
> similar to typeless code in Perl5. I'm not sure about the current
> state.
I see
> Anyway, in your example I hadn't expected a value coercion (from 10.1
> to 10), but something like an error if the type doesn't match.
this is what I'd like to see too, since I think it could help avoiding
casual errors, and the extensibility of the system is still safe because
of the multi things.
But I remember reading that, by default, perl6 will try to autocoerce
arguments.
Damn, I ignored the comment as if it were my own. :-)
Steffen
--
Steffen Schwigon <schw...@webit.de>
Dresden Perl Mongers <http://dresden-pm.org/>
Deutscher Perl-Workshop <http://www.perl-workshop.de/>