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: 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 CCat in item context emulates the CStr 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:
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 CCat in item context
emulates the CStr 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:
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:x 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'
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:x 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'
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'
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:x 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'
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:x 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: [svn:perl6-synopsis] r14414 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: @@ -562,10 +625,10 @@ @list xx $count Evaluates the left argument in list context, replicates the resulting -Capture value the number of time specified by the right argument and +CCapture value the number of time specified by the right argument and Presumably that should be number of times. -- Aaron Crane
[svn:perl6-synopsis] r14415 - doc/trunk/design/syn
Author: larry
Date: Sun Jun 3 17:23:15 2007
New Revision: 14415
Modified:
doc/trunk/design/syn/S03.pod
doc/trunk/design/syn/S04.pod
doc/trunk/design/syn/S06.pod
Log:
typo from Aaron Crane++
s/cat/list/ for flattening captures in order
cat() now only produces pseudo-strings even in list context
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podSun Jun 3 17:23:15 2007
@@ -610,7 +610,7 @@
$string x $count
Evaluates the left argument in string context, replicates the resulting
-string value the number of time specified by the right argument and
+string value the number of times specified by the right argument and
returns the result as a single concatenated string regardless of context.
If the count is less than 1, returns the null string.
@@ -625,7 +625,7 @@
@list xx $count
Evaluates the left argument in list context, replicates the resulting
-CCapture value the number of time specified by the right argument and
+CCapture value the number of times specified by the right argument and
returns the result in a context dependent fashion. If the operator
is being evaluated in ordinary list context, the operator returns a
flattened list. In slice (C@@) context, the operator converts each
CCapture
@@ -3554,15 +3554,12 @@
...
}
-To read arrays serially rather than in parallel, use Ccat(@x;@y).
-This wins a useless use of cat award in this case since you could
+To read arrays serially rather than in parallel, use Clist(@x;@y).
+This wins a useless use of list award in this case since you could
always just write C(@x,@y) to mean the same thing. But sometimes
it's nice to be explicit about that:
-@foo := [[1,2,3],[4,5,6]]; say cat([;] @foo); # 1,2,3,4,5,6
-
-(The Ccat function is not entirely useless; it also provides stringy
-semantics in string context.)
+@foo := [[1,2,3],[4,5,6]]; say list([;] @foo); # 1,2,3,4,5,6
=head1 Minimal whitespace DWIMmery
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podSun Jun 3 17:23:15 2007
@@ -391,14 +391,11 @@
for %hash.kv - $key, $value { print $key = $value\n }
-To process two arrays in parallel, use the Ceach function:
+To process two arrays in parallel use the Czip function to generate a
+list that can be bound to the corresponding number of parameters:
-for each(@a;@b) - $a, $b { print [$a, $b]\n }
-
-or use the Czip function to generate a list of CSeq objects that each can
-be bound to multiple arguments enclosed in square brackets:
-
-for zip(@a;@b) - [$a, $b] { print [$a, $b]\n }
+for zip(@a;@b) - $a, $b { print [$a, $b]\n }
+for @a Z @b - $a, $b { print [$a, $b]\n }# same thing
The list is evaluated lazily by default, so instead of using a Cwhile
to read a file a line at a time as you would in Perl 5:
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podSun Jun 3 17:23:15 2007
@@ -1060,16 +1060,16 @@
Various contexts may or may not be expecting multi-dimensional slices
or feeds. By default, ordinary arrays are flattened, that is, they
-have cat semantics. If you say
+have list semantics. If you say
(0..2; 'a'..'c') == my @tmp;
for @tmp { .say }
then you get 0,1,2,'a','b','c'. If you have a multidim array, you
-can ask for cat semantics explicitly with cat():
+can ask for list semantics explicitly with list():
(0..2; 'a'..'c') == my @@tmp;
-for @@tmp.cat { .say }
+for @@tmp.list { .say }
As we saw earlier, zip produces an interleaved result by taking one element
from each list in turn, so
Re: [svn:perl6-synopsis] r14415 - doc/trunk/design/syn
[EMAIL PROTECTED] wrote: Author: larry Date: Sun Jun 3 17:23:15 2007 New Revision: 14415 Modified: doc/trunk/design/syn/S03.pod doc/trunk/design/syn/S04.pod doc/trunk/design/syn/S06.pod Log: typo from Aaron Crane++ s/cat/list/ for flattening captures in order cat() now only produces pseudo-strings even in list context Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podSun Jun 3 17:23:15 2007 @@ -610,7 +610,7 @@ $string x $count Evaluates the left argument in string context, replicates the resulting -string value the number of time specified by the right argument and +string value the number of times specified by the right argument and returns the result as a single concatenated string regardless of context. If the count is less than 1, returns the null string. @@ -625,7 +625,7 @@ @list xx $count Evaluates the left argument in list context, replicates the resulting -CCapture value the number of time specified by the right argument and +CCapture value the number of times specified by the right argument and returns the result in a context dependent fashion. If the operator is being evaluated in ordinary list context, the operator returns a flattened list. In slice (C@@) context, the operator converts each CCapture @@ -3554,15 +3554,12 @@ ... } -To read arrays serially rather than in parallel, use Ccat(@x;@y). -This wins a useless use of cat award in this case since you could +To read arrays serially rather than in parallel, use Clist(@x;@y). +This wins a useless use of list award in this case since you could always just write C(@x,@y) to mean the same thing. But sometimes it's nice to be explicit about that: -@foo := [[1,2,3],[4,5,6]]; say cat([;] @foo); # 1,2,3,4,5,6 - -(The Ccat function is not entirely useless; it also provides stringy -semantics in string context.) +@foo := [[1,2,3],[4,5,6]]; say list([;] @foo); # 1,2,3,4,5,6 Let me see if I understand this correctly: * In list context, a list of captures gets flattened. * In slice context (a variant of list context), a list of captures doesn't get flattened. * In hash context (another variant of list context), a list of captures gets flattened, and then grouped into Pairs. * In item context, a list of captures becomes a single Array object, and the question about whether or not it gets flattened gets deferred until its contents get looked at in list, slice, or hash context. Meanwhile, 'zip' produces a list of captures - which, because list context is the default plural context, immediately gets flattened most of the time. As I see it, then, the serial equivalent to 'zip(@a;@b)' would be '(@a;@b)', and 'list(@a;@b)' would be the serial equivalent to 'list(zip(@a;@b))'. Or does '(@a;@b)' default to slice context? -- Jonathan Dataweaver Lang
