sub MAIN #= Print fibonacci values.
(*@argv); #= eg 10 20 prints 55 6765
print .[ @argv ] # print fibonacci values.
given
0, 1, 1, 2, 3, 5, # First fibonacci
values.
sub fib ( $m, $n ) # Fibonacci generator
{ $m + $n } ... Inf # to compute the rest.** .say for [\**] 2,3,4
4 # 4
81 # 3 ** 4
2417851639229258349412352 # 2 ** 3 ** 4 sub double(Int $x) { $x * 2 }
double '42'
SORRY! Error while compiling ...
Calling double(Str) will never work with declared signature (Int $x)
(Int $x)
sub date-range(Date $from, Date $to) { $from..$to }
say date-range '2000-01-01', '2023-08-21';
sub date-range(Date() $from, Date() $to) { $from..$to }
sub date-range(Date(Str) $from, Date(Str) $to) { $from..$to }
What do you mean? All the keywords in the standard language are ASCII. And even if you meant some other part of the standard language, they're (almost) all ASCII too.
(The most notable exceptions are use of superscript 0 thru 9 for powers -- eg `2¹⁶-1 == 65535` -- and the `«` and `»` characters, which are part of the Latin-1 aka "8 bit ASCII" character set, are aliases for the (7 bit) ASCII `<<` and `>>` tokens. I understand these exceptions may concern you, but can assure you they're not really a problem in practice.)
> The problem with sigils is that they compose poorly when casting
Are you thinking Raku sigils are like sigils in other languages, eg Perl or Javascript or PHP?
From my perspective one of the several _strengths_ of Raku's sigils is that they combine succinct compile time type constraints and composition.
Just type `@` (reads as "at") to denote a compile time enforced type constraint for the `Positional` interface, an abstract/generic datatype for any iterable integer indexed collection.
So, if you have an array of points, Raku will happily let you store it in a variable named, say, `points-array`, but naming it `@points` means Raku will compile time enforce binding of that name to an integer indexed collection and visually reflect that that is so for any human glancing at the code.
As for "casting", if you want to treat `@points` as a Single Item ("a single array of points") then just write `$@points` -- the `$` reads as Single Item -- `S` over `I`.
(Technically speaking that's not time consuming casting, but just stripping off an indirection, the optimal optimization of that scenario, but I am guessing this is semantically the kind of thing you meant.)
> (refs, counts)
Again, are you thinking that Raku's sigils are like other languages'? (They're not.)
> and do not generalize to other types.
Again, are you thinking that Raku's sigils are like other language's sigils? They are not.
Raku's `$` sigil is the generic Single Item interface for any datatype. (It can be parameterized with a data structure's typed structure.)
The `&` sigil is the generic Single Item interface for any function type. (It can be parameterized with a function's type signature.)
The `@` sigil covers any integer indexed collection. (It can be parameterized with the collection's fixed length for a fixed size array, or shape for a multidimensional structure. To parameterize a nested heterogeneous data structure's type signature, use `$` instead.)
The `%` sigil covers any name indexed collection. (It can be parameterized with the collection's key/value types. To parameterize a nested heterogeneous data structure's type signature, use `$` instead.)
> Plus, they seem to encourage the language designers to implement semantic that is "context aware" which would have been another billion dollars mistake if perl had become more popular.
Why are you mentioning Perl in a subthread about Raku? Are you aware the language was renamed precisely because so many people were completely misunderstanding the nature of Raku?
> In other words, that's unnecessary complexity bringing the attention to a poor type system. A bad idea that deserves to die, in my opinion.
If you're thinking of Perl's type system and applying what you know of that to Raku's, that's like thinking Python's type system is like Haskell's. They are very different.