From a code example, it looked like it was deconstructing the array, which was something I needed. In any case searching through the help browser for * yielded not so great results, plus I was expecting an array back from a slice, since it has always yielded arrays.
For good or ill, help search is geared toward method calls. * in this context isn’t a method call, so it’s not really searchable. I’m not sure what to do about that; I’d just observe that this exact same question comes up repeatedly on the forum.
However the * is irrelevant to the error here. The * always applies to the result of the entire expression:
The “impossible” expression is literally impossible. The first one works because you have an expression that should produce an array, and its members get distributed across function/method arguments. The second reads like “1/ slice; 2/ distribute this result across arguments; 3/ clump that” but because the values would have been distributed, there is no “that” object to clump. So it’s meaningless.
Therefore in a * call, any errors related to the expression have to be resolved within the expression. So the issue is that slice isn’t returning what you expected (and AFAICS slice is undocumented, so the only way to know is to read the method source). This error is occurring even before * is doing anything.
But here, is the * useful at all? The function has one argument, and you’re splitting the array across arguments… so the call will only print the first array element, which can be written more simply as a.slice(nil,0).clump(3).at(0) (and run faster too).
For good or ill, help search is geared toward method calls. * in this context isn’t a method call, so it’s not really searchable. I’m not sure what to do about that;
Online search engines actually are really useful when an official documentation search engine falls short. For instance, if you had the great ability to predict the exact description from the documentation you could type this into google
“evaluate the function with the arguments in an array” site:doc.sccode.org
And it will give you the correct page as well as a preview of the content where the search results are (though it won’t jump there when you click on the page). But this is only helpful if what you’re trying to figure out has intuitive keywords associated with it.
For example, in python this syntax is called argument unpacking. Granted, not everyone will know what that means, but it would definitely help for people that have seen it in similar languages if there was some mention of “unpacking” in the description.
If there’s some tutorial page that goes over using this syntax, you could also potentially include the word “asterisk” or “star” while describing the syntax because searching “*” isn’t very helpful for a number of reasons.
Another thing is to put it in more places in the documentation. For example, the Symbolic Notations page you linked is great, but I noticed there was a See Also: Syntax Shortcuts - I think it would probably be appropriate there as well!