What is the point of coercions like Int(Cool)?

What this does is accept a value that is a subtype of Cool, and tries to transform it into an Int. At that point it is an Int no matter what it was before.

So

sub double ( Int(Cool) $n ) { $n * 2 }

can really be thought of as ( I think this is how it was actually implemented in Rakudo )

# Int is a subtype of Cool otherwise it would be Any or Mu
proto sub double ( Cool $n ) {*}

# this has the interior parts that you write
multi sub double (  Int $n ) { $n * 2 }

# this is what the compiler writes for you
multi sub double ( Cool $n ) {
    # calls the other multi since it is now an Int
    samewith Int($n);
}

So this accepts any of Int, Str, Rat, FatRat, Num, Array, Hash, etc. and tries to convert it into an Int before calling &infix:<*> with it, and 2.

say double '  5  '; # 25
say double 2.5;     # 4
say double [0,0,0]; # 6
say double { a => 0, b => 0 }; # 4

You might restrict it to a Cool instead of Any as all Cool values are essentially required to provide a coercion to Int.

( :( Int(Any) $ ) can be shortened to just :( Int() $ ) )

The reason you might do this is that you need it to be an Int inside the sub because you are calling other code that does different things with different types.

sub example ( Int(Cool) $n ) returns Int {
    other-multi( $n ) * $n;
}

multi sub other-multi ( Int $ ) { 10 }
multi sub other-multi ( Any $ ) {  1 }

say example 5;   # 50
say example 4.5; # 40

In this particular case you could have written it as one of these

sub example ( Cool $n ) returns Int {
    other-multi( Int($n) ) * Int($n);
}

sub example ( Cool $n ) returns Int {
    my $temp = Int($n);
    other-multi( $temp ) * $temp;
}

sub example ( Cool $n is copy ) returns Int {
    $n = Int($n);
    other-multi( $n ) * $n;
}

None of them are as clear as the one that uses the signature to coerce it for you.

Normally for such a simple function you can use one of these and it will probably do what you want.

my &double = * * 2; # WhateverCode
my &double = * × 2; # ditto

my &double = { $_ * 2 };       # bare block
my &double = { $^n * 2 };      # block with positional placeholder
my &double = -> $n { $n * 2 }; # pointy block

my &double = sub ( $n ) { $n * 2 } # anon sub
my &double = anon sub double ( $n ) { $n * 2 } # anon sub with name

my &double = &infix:<*>.assuming(*,2); # curried
my &double = &infix:<*>.assuming(2);

sub double ( $n ) { $n * 2 } # same as :( Any $n )

Update Having reviewed this answer today I've concluded I had completely misunderstood what @musiKk was getting at. This was revealed most clearly in @darch's question and @musiKk's response:

@darch: Or is your question why one might prefer Int(Cool) over Int(Any)? If that's the case, that would be the question to ask.

@musiKk: That is exactly my question. :)

Reviewing the many other answers I see none have addressed it the way I now think it warrants addressing.

I might be wrong of course so what I've decided to do is leave the original question as is, in particular leaving the title as is, and leave this answer as it was, and instead write a new answer addressing @darch's reformulation.

Specify parameter type, with no coercion: Int $x

We could declare:

sub double (Int $x) { ... } # Accept only Int. (No coercion.)

Then this would work:

double(42);

But unfortunately typing 42 in response to this:

double(prompt('')); # `prompt` returns the string the user types

causes the double call to fail with Type check failed in binding $x; expected Int but got Str ("42") because 42, while looking like a number, is technically a string of type Str, and we've asked for no coercion.

Specify parameter type, with blanket coercion: Int() $x

We can introduce blanket coercion of Any value in the sub's signature:

sub double (Int(Any) $x) { ... } # Take Any value. Coerce to an Int.

Or:

sub double (Int() $x)    { ... } # Same -- `Int()` coerces from Any.

Now, if you type 42 when prompted by the double(prompt('')); statement, the run-time type-check failure no longer applies and instead the run-time attempts to coerce the string to an Int. If the user types a well-formed number the code just works. If they type 123abc the coercion will fail at run-time with a nice error message:

Cannot convert string to number: trailing characters after number in '123⏏abc'

One problem with blanket coercion of Any value is that code like this:

class City { ... } # City has no Int coercion
my City $city;
double($city);

fails at run-time with the message: "Method 'Int' not found for invocant of class 'City'".

Specify parameter type, with coercion from Cool values: Int(Cool) $x

We can choose a point of balance between no coercion and blanket coercion of Any value.

The best class to coerce from is often the Cool class, because Cool values are guaranteed to either coerce nicely to other basic types or generate a nice error message:

# Accept argument of type Cool or a subclass and coerce to Int:
sub double (Int(Cool) $x) { ... }

With this definition, the following:

double(42);
double(prompt(''));

works as nicely as it can, and:

double($city);

fails with "Type check failed in binding $x; expected Cool but got City (City)" which is arguably a little better diagnostically for the programmer than "Method 'Int' not found for invocant of class 'City'".

why would foo care that the to-be-coerced type is a Foo in the first place?

Hopefully it's now obvious that the only reason it's worth limiting the coerce-from-type to Foo is because that's a type expected to successfully coerce to a Bar value (or, perhaps, fail with a friendly message).

Could someone shed some light on this? Links to appropriate documentation and parts of the spec are appreciated as well. I couldn't find anything useful there.

The document you originally quoted is pretty much all there is for enduser doc. Hopefully it makes sense now and you're all set. If not please comment and we'll go from there.


Am I missing something? I'm not a Perl 6 expert, but it appears the syntax allows one to specify independently both what input types are permissible and how the input will be presented to the function.

Restricting the allowable input is useful because it means the code will result in an error, rather than a silent (useless) type conversion when the function is called with a nonsensical parameter.

I don't think an example where the two types are not in a hierarchical relationship makes sense.

Tags:

Raku

Recent Posts