Chas Owens wrote:
Jonathan Lang wrote:
> Chas Owens wrote:
> > Jonathan Lang wrote:
> > > Is there any reason why we can't simply define '$a x $n' as being
> > > shorthand for 'cat($a xx $n)'? In what way does the former differ
> > > from the latter, other than the use of a Whatever in place of $n?
> > "$a x $n" is equivalent to "join '', $a xx $n", but that isn't an apt
> > description of its behavior. "cat($a xx *)" is an attempt to provide
> > an infinite string since 'a' x Inf would result in memory overflow
> > (but the cat trick works since lists are evaluated lazily).
> Then it looks to me like 'cat($a xx $n)' is more flexible than "join
> '', $a xx $n", and would work better as the baseline definition for
> '$a x $n'. Is there any reason to prefer a join-based definition to a
> cat-based one? AFAICT, the only thing that 'join' can do that 'cat'
> can't is to provide a delimiter when stitching the component strings
> together; in the case of 'x', this feature is (rightfully) not being
Okay, maybe my understanding of the cat function is flawed, but I
thought it walked through each array handed to it in a serial fashion
(as opposed to zip which walks the arrays in a parallel fashion).
Hmm... true enough. That was an aspect of the 'cat' function that I
hadn't been aware of. Rather, what came to mind when I saw the 'cat'
function was the following (from S29): "...a C<Cat> in item context
emulates the C<Str> interface lazily."
In short, 'cat("a" x 5)' effectively _is_ a scalar string value of
five characters - in item context. And because it emulates the string
interface _lazily_, there's no danger from an infinitely long string.
Again, I was not aware that there _was_ a distinct list context result
for 'cat'; and I'm pretty sure that it was referenced as an
alternative to '$a x *' due to its behavior in scalar context, rather
than its behavior in list context.
So the question is this: is there a problem with "'a' x 5" producing
"'a', 'a', 'a', 'a', 'a'" in list context, and 'aaaaa' in item
context? Or should it produce the latter in anything but void
Jonathan "Dataweaver" Lang