Functions in Raku tend to have one job and one job only.
`split` splits a string.
So if you call `split` on something that is not a string it gets turned
into one if it can.
This happens for most functions.
Having `split` be the only function that auto-vectorizes against an array
would be very confusing.
If it isn't the only function, then you have to come up with some list of
functions which do vectorize.
Then every single person has to memorize that list in its entirety. Which
can be difficult even for experts.
Perl has a similar list of functions which automatically work on `$_`, and
almost no one has that list memorized.
Raku very specifically did not copy that idea.
---
Raku instead has high level concepts that it uses consistently.
One of those concepts is that functions have one job and one job only.
So if you call `chars` on anything it gets turned into a string first.
On Sat, Oct 10, 2020 at 4:23 PM William Michels via perl6-users <
perl6-us...@perl.org> wrote:
> So I guess the first question I have is whether the 'auto-joining' of
> array elements is specc'ed or not.
>
> What you seem to be saying is that when calling a function on an array,
> the first response is for Raku to call something similar to 'cat' on the
> array, 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'.
>
> I can point to the (functional) R-programming language to show what
> happens there. When manipulating "array-like" (i.e. vector) objects in R,
> you can do nested function calls, or sequential (piped) function calls, and
> still get the same data structure out at the end. So a 10-element input
> gives a 10-element output. In the R-GUI (i.e. REPL):
>
> > 0:9
> [1] 0 1 2 3 4 5 6 7 8 9
> > x <- 0:9
> > is.vector(x)
> [1] TRUE
> > length(x)
> [1] 10
> > # using base-R:
> > sqrt(tan(cos(sin(x))))
> [1] 1.2479614276 0.8867679488 0.8398446968 1.2344525173 0.9431819962
> 0.8044843661 1.1966884594
> [8] 1.0064589934 0.7823305851 1.1415611482
> > x ->.; sin(.) ->.; cos(.) ->.; tan(.) ->.; sqrt(.)
> [1] 1.2479614276 0.8867679488 0.8398446968 1.2344525173 0.9431819962
> 0.8044843661 1.1966884594
> [8] 1.0064589934 0.7823305851 1.1415611482
> > library(magrittr) # add a "piping" library:
> > x %>% sin %>% cos %>% tan %>% sqrt
> [1] 1.2479614276 0.8867679488 0.8398446968 1.2344525173 0.9431819962
> 0.8044843661 1.1966884594
> [8] 1.0064589934 0.7823305851 1.1415611482
> > y <- x %>% sin %>% cos %>% tan %>% sqrt
> > is.vector(y)
> [1] TRUE
> > length(y)
> [1] 10
> >
>
> Now it's true that R has a greatly simplified memory/storage model
> compared to Raku. But it's not hard to follow the R-code above, even if you
> don't know the language. If at the end of all your function calls you want
> to stringify and 'collapse' your 10 element vector into a single element
> string, you call paste() on your object, which has a user-definable
> 'collapse' argument that defaults to NULL. [For anyone worried about
> formatting actual output, R has print() and sprintf() and cat() functions
> as well]:
>
> > length(paste(0:9, y))
> [1] 10
> > paste(0:9, y)
> [1] "0 1.24796142755091" "1 0.886767948777031" "2 0.839844696795443" "3
> 1.23445251727454"
> [5] "4 0.943181996210625" "5 0.804484366108825" "6 1.19668845937773" "7
> 1.00645899343325"
> [9] "8 0.782330585082487" "9 1.14156114815661"
> > length(paste(0:9, "=", y, collapse= "; "))
> [1] 1
> > paste(0:9, "=", y, collapse= "; ")
> [1] "0 = 1.24796142755091; 1 = 0.886767948777031; 2 = 0.839844696795443;
> 3 = 1.23445251727454; 4 = 0.943181996210625; 5 = 0.804484366108825; 6 =
> 1.19668845937773; 7 = 1.00645899343325; 8 = 0.782330585082487; 9 =
> 1.14156114815661"
> >
>
> When I started learning Perl6/Raku a few years ago I actually wondered
> where the different programming paradigms would be delineated. Would
> imperative/structural/procedural code be 'closer to the metal' while
> functional code would be applied to higher-order data structures like
> arrays, arrays-of-lists, arrays-of-hashes, and arrays-of-arrays? And those
> higher-order data structures would then be utilized in object-oriented
> code, i.e. the programmer would be manipulating classes and class-based
> objects of varying complexity to produce a robust and secure program? Or
> would Raku implement a different (i.e. better) paradigm hierarchy that I
> hadn't anticipated?
>
> Best Regards, Bill.
>
> W. Michels, Ph.D.
>
>
>
>
>
> On Tue, Oct 6, 2020 at 1:59 PM Tobias Boege <t...@taboege.de> wrote:
>
>> On Tue, 06 Oct 2020, William Michels via perl6-users wrote:
>> > [...]
>> >
>> > So my question regards "special-casing" of split/join in Raku. Is the
>> first
>> > result on comma-delimited data the default, i.e. joining disparate
>> elements
>> > of an array together head-to-tail? Or is the second result on
>> > whitespace-delimited data the default (i.e. no joining of disparate
>> > elements together head-to-tail)? Which one is special-cased? If the
>> second
>> > one is special-cased, is that why Raku returns 5 elements and not 4
>> > elements as in lines C/D (implied join)?
>> >
>>
>> My answer is going to be that there is *no* special-casing. You have an
>> array of strings @a and you call the `split` and `join` methods on it.
>> These two methods are not alike. `join` is a proper method of List and
>> it joins stringifications of the elements of that list.
>>
>> Crucially, the `split` method comes from somewhere else: Array inherits
>> it from the Cool class. When you call Array.split, what happens is that
>> your entire array gets stringified first (joining stringifications of
>> its elements with spaces) and then Cool.split is called on that string
>> representation of your array. This is even mentioned in the introductory
>> paragraph about Cool [1].
>>
>> This is the strangely consistent explanation of the effects you observed.
>> You see, the only "special" thing is that Array.split being a Cool method
>> causes the array to be joined with *spaces* before the splitting starts,
>> but this always happens, independently of the join/split arguments.
>>
>> Array.split does in particular *not* "pass on" the split call to the
>> elements of the array. For that you would use @a».split, although this
>> would cause (itemized) Seqs for each element of @a to end up in the
>> returned list, so what you actually thought you were doing may be
>> written as
>>
>> @a».&{ .split(",").Slip }
>>
>> I am sure there are ways to write it more alphabetically.
>>
>> Best,
>> Tobias
>>
>> [1] https://docs.raku.org/type/Cool
>>
>> --
>> "There's an old saying: Don't change anything... ever!" -- Mr. Monk
>>
>
