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
>
