Here's another way of phrasing these answers-
Some routines like "join" operate on strings, and thus coerce their
argument to a string.
Some routines like "sin" operate on numbers, and thus coerce their argument
to a number.
Each class defines how it coerces to Str or Num, regardless of what is
doing the coercing. Array defines its Str coersion as *.join(' ') and its
Num coercion as *.items
Sometimes those coercions are very helpful, like letting "put" write string
representations of all sorts of things with no extra work for the developer.
Other times, they are not so helpful, instead be explicit what you want the
routine to work on- don't rely on coercion to the string or num the routine
expects. With arrays, follow Larry's advice and use the >> hyperoperator,
if that's what you want.
There's no "context" in the Perl sense, that history refers to a
"wantarray" built-in where a subroutine would ask if the return value was
assigned to an array or not, and then behave differently. Raku doesn't have
that.
https://docs.raku.org/language/5to6-perlfunc#index-entry-wantarray_-_perlfunc
-y
On Mon, Oct 12, 2020 at 6:44 PM William Michels via perl6-users <
perl6-us...@perl.org> wrote:
>
>
> On Sat, Oct 10, 2020 at 4:49 PM Tobias Boege <t...@taboege.de> wrote:
>
>> On Sun, 11 Oct 2020, Tobias Boege wrote:
>> > On Sat, 10 Oct 2020, William Michels via perl6-users wrote:
>> > > then proceed to process the function call. As it is my understanding
>> that
>> > > Raku incorporates a lot of different programming paradigms
>> (imperative,
>> > > object-oriented, functional, etc.), I'm not sure where this behavior
>> falls
>> > > on the 'paradigm ladder'.
>> > >
>> >
>> > If you want to view it as a matter of paradigm, I guess it would be the
>> > "operator-centric paradigm", except that it is a method and not an
>> operator.
>> >
>> > The Array class inherits methods from Cool and when you call a method
>> from
>> > Cool on the Array, the Cool part of the array will answer the call. The
>> > Array is Cool to advertise that it can be evaluated in numeric and
>> string
>> > "context". In string context, the array becomes joined using spaces as
>> > delimiters. Put more bluntly: when you treat an array like a string
>> > (by calling a string-related method of Cool on it), then Raku treats it
>> > as a string, even if it must convert it to one before. [ This may sound
>> > magical, but in reality Array just obtains the method .split from Cool
>> > and its implementation explicitly converts the invocant, whatever it
>> > may be, to a Stringy on which a sensible split is defined. ]
>> >
>>
>> Oh, it seems like I was far too slow. From all the other answers, I think
>> Brad put best what I tried to express using many redundant words. And he
>> avoided the historically charged and probably inaccurate term "context".
>>
>> Best,
>> Tobias
>>
>
>
> Thank you, Tobias!
>
> user@mbook~$ raku #test numeric function calls on array
> user@mbook~$ raku #enter REPL
> To exit type 'exit' or '^D'
> > my @nums = 0, π/2, 3 * π/2;
> [0 1.5707963267948966 4.71238898038469]
> > say @nums.elems
> 3
> > say @nums.sin.elems
> 1
> > say @nums.sin
> 0.1411200080598672
> > say @nums.elems.sin
> 0.1411200080598672
> > say sin(3)
> 0.1411200080598672
> > $*VM
> moar (2020.06)
> >
>
> At first perusal one might conclude that calling .sin on an array
> "auto-joins" the arrays elements, but in fact, calling .sin on an array
> returns the sin() of the number of array elements. The two calls
> "@nums.sin" and "@nums.elems.sin" give exactly the same result.
>
> I'm ignorant of the 'historically charged' use of the term 'context',
> although I interpret your comment to suggest that the term 'context' now
> may be a disfavored concept. If so, then all the more reason to obviate the
> need to explain this concept to new Raku programmers.
>
> --Best, Bill.
>
