On Sat, 10 Oct 2020, William Michels via perl6-users wrote: > So I guess the first question I have is whether the 'auto-joining' of array > elements is specc'ed or not. >
I did not find anything that explicitly requires @array.split() to force @array into a string, but there are tests in S02-types/list.t asserting that stringified lists must use a space as delimiter. > 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, No, definitely not. At least not "any function". Only functions (or methods or operators) by which you express the intent to treat the array as a string. > 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. ] The same principle makes code like `"2" ** 5` or `2.map: * ** 5` work, where in the first case a string 2 is treated as, and hence converted to, a number, and in the second case an integer is treated like a list and indeed Raku will arrange for that to happen on the fly. In those two cases it is exponentiation that forces the invocant to become a numberic and it is mapping that forces the invocant to become a listy thing transparently. In the same way splitting something forces it to become a string first. [ Again, it is not the language that somehow picks up *syntactical* clues from your code about what to convert to what, but it is the core implementation of, e.g., Any.map which is inherited by Int, in the above example, and converts whatever its invocant is to something that is iterable, because iteration is what you wanted to happen by calling .map on it. ] > 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 Yes, so it seems that R prefers to vectorize function calls over arrays. In Raku, if you want to apply a method or sub or operator to every element of a list instead of the list object itself (which may have its own over- load or inherited version of that method causing it to behave strangely, which is the topic of this thread), you ought to use `map` or a hyper operator. In Raku, if you call sin on an array, that puts the array in a numeric context which makes the array collapse to the closest numeric thing that Raku makes the convention to associate with it: the number of its elements. Behold: my @x = 0..9; say @x.sin; #= -0.5440211108893698 = sin(10) This is an excellent example you chose, because .sin and .split both become methods of Array because Array inherits Cool. They both do not apply element-wise but cause the entire invocant array to adapt to context -- they become a number or a string depending on how you want to treat it. Best, Tobias -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk
