Re: 'x' vs. 'xx'
Chas Owens wrote: The current Perl 5 behavior is [EMAIL PROTECTED]:~$ perl -le 'my @a = ("-" x 5, "foo", "-" x 5); print "@a"' - foo - [EMAIL PROTECTED]:~$ perl -le 'my @a = (("-") x 5, "foo", ("-") x 5); print "@a"' - - - - - foo - - - - - I am against anything other than that for x or xx without a really compelling reason. ...with x always corresponding to the first and xx always corresponding to the second, right? In essence, x always produces a string, while xx always produces a list. Jonathan Lang wrote: > Personally, I would tend to favor the notion that infix: always > produces a single string. With this in mind, I'm now leaning toward > "~cat($a xx $n)" as the more verbose equivalent of "$a x $n". You > always produce a single string, and you do so lazily (according to the > way that 'cat' works in item context). I assume it is a bug in Pugs implementation of cat, but pugs> ~cat('a' xx 5) "a a a a a" Yes, that would be a bug - probably closely tied to the fact that pugs doesn't implement cat properly in item context. IIRC, the original inspiration for the 'cat' function was 'concatenate' - thus, in item context at least, one would expect 'cat' to resemble '[~]'. I also am having a hard time figuring out why I would want an infinite string. My first thought was something like my $ten_zeros = substr(cat(0 xx *), 0, 10); but that is more clearly written as my $ten_zeros = 0 x 10; I'll punt the practical usage to someone else, other than to suggest that the goal of using an asterisk for the number of repetitions isn't so much to produce an "infinite string" as a "string of arbitrary length". Remember, '*' ne 'Inf'; '*' eq 'Whatever'. A practical use for '~cat($string xx *)' would most likely be one that relies on the arbitrariness of the number of repetitions. Hmm... how about something like: if $a gt ~cat('-' xx *) { ... } or, if 'x' is defined along the lines that I'm considering: if $a gt '-' x * { ... } Bear in mind that you're not limited to single-character repetitions: if $a lt '142857' x * { ... } In short, the string will get replicated exactly as many times as is needed to resolve the comparison. -- Jonathan "Dataweaver" Lang
Re: 'x' vs. 'xx'
On 6/3/07, Jonathan Lang <[EMAIL PROTECTED]> wrote: snip From what you're saying, I get the impression that you think that "'-' x 5" ought to produce a single string of five dashes regardless of whether the context is item or list. Correct? (Note: I'm not asking about what the spec says, since what it says is potentially up for revision, given sufficient cause; I'm asking about what you think the spec _should_ say.) If so, "cat($n xx *)" is not an adequate replacement for "$n x *", since it produces a list of one-character strings if used in list context. OTOH, "~cat($n xx *)" might work. snip The current Perl 5 behavior is [EMAIL PROTECTED]:~$ perl -le 'my @a = ("-" x 5, "foo", "-" x 5); print "@a"' - foo - [EMAIL PROTECTED]:~$ perl -le 'my @a = (("-") x 5, "foo", ("-") x 5); print "@a"' - - - - - foo - - - - - I am against anything other than that for x or xx without a really compelling reason. snip Personally, I would tend to favor the notion that infix: always produces a single string. With this in mind, I'm now leaning toward "~cat($a xx $n)" as the more verbose equivalent of "$a x $n". You always produce a single string, and you do so lazily (according to the way that 'cat' works in item context). -- Jonathan "Dataweaver" Lang I assume it is a bug in Pugs implementation of cat, but pugs> ~cat('a' xx 5) "a a a a a" I also am having a hard time figuring out why I would want an infinite string. My first thought was something like my $ten_zeros = substr(cat(0 xx *), 0, 10); but that is more clearly written as my $ten_zeros = 0 x 10;
Re: 'x' vs. 'xx'
Mark J. Reed wrote: Is "item context" what we're calling scalar these days, or something else? According to S03, it does indeed appear that "item context" is the current terminology for what perl 5 called "scalar context": The item contextualizer item foo() The new name for Perl 5's scalar contextualizer. Equivalent to $(). We still call the values scalars, and talk about "scalar operators", but scalar operators are those that put their arguments into item context. -- Jonathan "Dataweaver" Lang
Re: 'x' vs. 'xx'
Is "item context" what we're calling scalar these days, or something else? On 6/3/07, Jonathan Lang <[EMAIL PROTECTED]> wrote: Chas Owens wrote: > I am almost certain that the following code is in list context. > > pugs> my @a = '-' x 5, 'foo', '-' x 5; > pugs> @a > ("-", "foo", "-") > pugs> my @b = cat('-' xx 5), 'foo', cat('-' xx 5) > ("-", "-", "-", "-", "-", "foo", "-", "-", "-", "-", "-") > > However, it does seem that Pug's version of cat does not handle the > Str emulation, so that may fix it, but I don't see how it could since > (at least in my mind) the code above is in list context. You're right; it is. From what you're saying, I get the impression that you think that "'-' x 5" ought to produce a single string of five dashes regardless of whether the context is item or list. Correct? (Note: I'm not asking about what the spec says, since what it says is potentially up for revision, given sufficient cause; I'm asking about what you think the spec _should_ say.) If so, "cat($n xx *)" is not an adequate replacement for "$n x *", since it produces a list of one-character strings if used in list context. OTOH, "~cat($n xx *)" might work. Personally, I would tend to favor the notion that infix: always produces a single string. With this in mind, I'm now leaning toward "~cat($a xx $n)" as the more verbose equivalent of "$a x $n". You always produce a single string, and you do so lazily (according to the way that 'cat' works in item context). -- Jonathan "Dataweaver" Lang -- Mark J. Reed <[EMAIL PROTECTED]>
Re: 'x' vs. 'xx'
Chas Owens wrote: I am almost certain that the following code is in list context. pugs> my @a = '-' x 5, 'foo', '-' x 5; pugs> @a ("-", "foo", "-") pugs> my @b = cat('-' xx 5), 'foo', cat('-' xx 5) ("-", "-", "-", "-", "-", "foo", "-", "-", "-", "-", "-") However, it does seem that Pug's version of cat does not handle the Str emulation, so that may fix it, but I don't see how it could since (at least in my mind) the code above is in list context. You're right; it is. From what you're saying, I get the impression that you think that "'-' x 5" ought to produce a single string of five dashes regardless of whether the context is item or list. Correct? (Note: I'm not asking about what the spec says, since what it says is potentially up for revision, given sufficient cause; I'm asking about what you think the spec _should_ say.) If so, "cat($n xx *)" is not an adequate replacement for "$n x *", since it produces a list of one-character strings if used in list context. OTOH, "~cat($n xx *)" might work. Personally, I would tend to favor the notion that infix: always produces a single string. With this in mind, I'm now leaning toward "~cat($a xx $n)" as the more verbose equivalent of "$a x $n". You always produce a single string, and you do so lazily (according to the way that 'cat' works in item context). -- Jonathan "Dataweaver" Lang
Re: 'x' vs. 'xx'
On 6/3/07, Jonathan Lang <[EMAIL PROTECTED]> wrote: 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 > > used. > > 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 in item context emulates the C 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 'a' in item context? Or should it produce the latter in anything but void context? -- Jonathan "Dataweaver" Lang I am almost certain that the following code is in list context. pugs> my @a = '-' x 5, 'foo', '-' x 5; pugs> @a ("-", "foo", "-") pugs> my @b = cat('-' xx 5), 'foo', cat('-' xx 5) ("-", "-", "-", "-", "-", "foo", "-", "-", "-", "-", "-") However, it does seem that Pug's version of cat does not handle the Str emulation, so that may fix it, but I don't see how it could since (at least in my mind) the code above is in list context.
Re: 'x' vs. 'xx'
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 > used. 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 in item context emulates the C 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 'a' in item context? Or should it produce the latter in anything but void context? -- Jonathan "Dataweaver" Lang
Re: 'x' vs. 'xx'
On 6/3/07, Jonathan Lang <[EMAIL PROTECTED]> 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 used. -- Jonathan "Dataweaver" Lang 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). If that is the case then ("a" x 5) ne cat("a" xx 5). The former produces a scalar string value of five characters and the other produces a list of one character scalar string values. My understanding is that the cat function and the xx operator are being used in the documentation to mimic what an _infinite_ string (not a normal string) would look like. Since you cannot have an infinite string with the current implementation of scalars (memory would give out), a list with lazy evaluation is used; however, you could not just drop cat("a" xx *) into a spot where you you were using "a" x 5.
Re: 'x' vs. 'xx'
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 used. -- Jonathan "Dataweaver" Lang
Re: 'x' vs. 'xx'
On 6/2/07, Jonathan Lang <[EMAIL PROTECTED]> 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? -- Jonathan "Dataweaver" Lang "$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).
'x' vs. 'xx'
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? -- Jonathan "Dataweaver" Lang