TSa:
> Perhaps we
> can live with the numerically lower end always beeing part
> of the range, the larger one never,
I don't think so.
>0 .. 5 == ( 0, 1, 2, 3, 4)
{ action } for 0 .. 5
is supposed to run for 0,1,2,3,4,5.
But '0 .. ^5' should not mean '( 0, 1, 2, 3, 4, 5)' just becaus
HaloO,
0 .. 5 == ( 0, 1, 2, 3, 4)
Hmm, and 0..5.1 == (0,1,2,3,4,5) to "rescue" the end.
--
HaloO,
Michele Dondi wrote:
IMHO the former is much more useful and common. Mathematically (say, in
combinatorics or however dealing with integers) when I happen to have to
do with a set of $n elements chances are to a large extent that it is
either 0..$n or 1..$n; 0..$n may lead to confusion
TSa:
> HaloO,
Hi!
> Ruud H.G. van Tol:
>> Yes, it could use a step:
>>
>> ^42.7 = (0, 7, 14, 21, 28, 35)
>> ^42.-7 = (35, 28, 21, 14, 7, 0)
>
> OK, fine if the step sign indicates reversal after creation.
> That is, the modulus is 7 in both cases.
>
>
>> ^-42.7 = (-35, -28, -21, -14, -7, 0)
> If .indexes turns out to be used a lot, then let's have .i -- "i" for
> "index" is accepted abbreviation, isn't it? (Think for (i = 0; ...;
> ...))
+1 here. I too find ^$n a bit bizarre, but I like the look of
for @foo.i
OTOH, I like the parallels between %foo.keys and @foo.keys -- it recalls
t
On Thu, Nov 24, 2005 at 12:42:25PM +0100, Juerd wrote:
: Ruud H.G. van Tol skribis 2005-11-24 10:36 (+0100):
: > > it's about expression.
: > Also if [EMAIL PROTECTED] is the multi-dimensional index zip?
:
: No.
:
: However, it does feel weird to have an *operator* that makes an array
: behave in
On Thu, Nov 24, 2005 at 12:08:44AM +0100, Stéphane Payrard wrote:
: What about array with holes as supported by Parrot?
We have prior art with hashes, but it's not clear how well that maps
across.
: Does .elems return the number of elements with or without
: the holes?
In Perl 5, non-existing ar
HaloO,
Ruud H.G. van Tol wrote:
Yes, it could use a step:
^42.7 = (0, 7, 14, 21, 28, 35)
^42.-7 = (35, 28, 21, 14, 7, 0)
OK, fine if the step sign indicates reversal after creation.
That is, the modulus is 7 in both cases.
^-42.7 = (-35, -28, -21, -14, -7, 0)
^-42.-7 = (0, -7, -14, -21
Juerd:
> Rob Kinyon:
>> What about @array.indices instead?
>
> Oops, I said "indexes" in a former message.
AFAIK they share most of their meanings nowadays.
(My old Chambers says that indexes are books.)
> Maybe a good candidate for an alias?
No doubt about it.
--
Affijn, Ruud
"Gewoon is ee
Juerd:
> I have no objections to [EMAIL PROTECTED] returning a list of indexes, if that
> is the definition.
It is what Mark suggested. Rob suggested to use .indices instead.
Looking at 'elem(ent)s' and 'ind(exe)s' and 'ind(ice)s', I toss up
'inds' or 'ixs'.
> I do object to [EMAIL PROTECTED] m
Rob Kinyon skribis 2005-11-24 0:44 (-0500):
> What about @array.indices instead?
Oops, I said "indexes" in a former message. Maybe a good candidate for
an alias?
> Then, there's no possible fenceposting, your code is self-documenting,
> and we're not introducing another unary operator?
++
Jue
Ruud H.G. van Tol skribis 2005-11-24 12:25 (+0100):
> [EMAIL PROTECTED]zip: @a.keys? @a.indices?
Special syntax, or special context?
> Indices can be sets of sparse ranges. A sparse range is a set of
> non-sparse ranges.
> [7..13; 0..5, 9..Inf].
I have no objections to [EMAIL PROTECTED] re
Ruud H.G. van Tol skribis 2005-11-24 10:36 (+0100):
> > it's about expression.
> Also if [EMAIL PROTECTED] is the multi-dimensional index zip?
No.
However, it does feel weird to have an *operator* that makes an array
behave in a certain way. Well, not weird, because we're used to context,
but ope
Juerd:
> Larry Wall:
>> [Peter Scott]:
>>> It seems strange to have a shortcut for 0..$n-1 but no shortcut
>>> for 0..$n.
>>
>> But then you'd usually want 1..$n instead...
>
> I think this illustrates very well that it's a bit silly to have a
> shortcut for just one of the three much-used ranges.
On Wed, 23 Nov 2005, Peter Scott wrote:
It seems strange to have a shortcut for 0..$n-1 but no shortcut for 0..$n.
IMHO the former is much more useful and common. Mathematically (say, in
combinatorics or however dealing with integers) when I happen to have to
do with a set of $n elements cha
Juerd:
> Ruud H.G. van Tol:
>>> Doesn't ^5 encourage [EMAIL PROTECTED] too much?
>>
>> Can you explain when that creates a problem?
>
> It's not about problems in execution,
That answers "when not". :)
> it's about expression.
Also if [EMAIL PROTECTED] is the multi-dimensional index zip?
>>
On 11/23/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> : I'm also puzzled that you feel the need to write 0..$n-1 so often; there
> : are so many alternatives to fenceposting in P5 that I almost never write
> : an expression like that, so why is it cropping up that much in P6?
>
> Couple reasons occu
Juerd skribis 2005-11-24 0:39 (+0100):
> Personally, I think even ^.., ^..^ and ..^ are too much, but that I can
> live with.
For the record, I don't want to die if ^ is introduced. If it's there,
I'll use it. If using [EMAIL PROTECTED] becomes accepted style, I'll use it.
The "live with" isn't
Larry Wall skribis 2005-11-23 13:10 (-0800):
> : It seems strange to have a shortcut for 0..$n-1 but no shortcut for 0..$n.
> But then you'd usually want 1..$n instead...
I think this illustrates very well that it's a bit silly to have a
shortcut for just one of the three much-used ranges. My view
Larry Wall a écrit :
| On Wed, Nov 23, 2005 at 07:10:39PM +0100, Juerd wrote:
| : Ruud H.G. van Tol skribis 2005-11-23 19:03 (+0100):
| : > > Doesn't ^5 encourage [EMAIL PROTECTED] too much?
| : > Can you explain when that creates a problem?
| :
| : It's not about problems in execution, it's about
On Wed, Nov 23, 2005 at 08:04:32AM -0800, Peter Scott wrote:
: On Tue, 22 Nov 2005 14:34:12 -0800, Larry Wall wrote:
: > What tipped me over the edge, however, is that I want ^$x back for a unary
: > operator that is short for 0..^$x, that is, the range from 0 to $x - 1. I
: > kept wanting such an
On Tue, 22 Nov 2005 14:34:12 -0800, Larry Wall wrote:
> What tipped me over the edge, however, is that I want ^$x back for a unary
> operator that is short for 0..^$x, that is, the range from 0 to $x - 1. I
> kept wanting such an operator in revising S09. It also makes it easy to
> write
>
>
On Wed, Nov 23, 2005 at 02:21:15PM -0500, Matt Fowles wrote:
: I like C< ..^5 > better than C< ^5 > actually. I was going for the
: rule that an omitted LHS was 0 and an omitted RHS was infinity (your
: probably cannot omit both).
But that only saves you 1 keystroke, and eliminates unary .. for a
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> One of the other reasons I like ^5 is that the uparrowness of it
LW> naturally reads as "up to 5". But for containers we could certainly
LW> abstract it out to the domain.
it also harkens back to apl's iota op which did similar thing
Larry~
On 11/23/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 23, 2005 at 11:55:35AM -0500, Matt Fowles wrote:
> : I think using C< ..5 > to mean (0, 1, 2, 3, 4) would be a more
> : sensible option. Makes sense to me at least.
>
> That doesn't derive well from any of:
>
> ..
> ^
On Wed, Nov 23, 2005 at 10:58:53AM -0800, Larry Wall wrote:
: Well, as I said in my other reply, that's not a big problem for
: 1-dimensional arrays. But it does possibly make sense that ^ on a
: multidimensional array or hash would return a zip of all the key sets.
: Plus it generalizes ^%hash to
On Wed, Nov 23, 2005 at 10:45:21AM -0800, Mark A. Biggar wrote:
: Actually I like that and think that ^$x should be 0..($x-1) and that
: [EMAIL PROTECTED] should be define to return the array's index set (usually
: 0..$#foo) but maybe something else for a non-zero based array.
Well, as I said in
On Wed, Nov 23, 2005 at 07:10:39PM +0100, Juerd wrote:
: Ruud H.G. van Tol skribis 2005-11-23 19:03 (+0100):
: > > Doesn't ^5 encourage [EMAIL PROTECTED] too much?
: > Can you explain when that creates a problem?
:
: It's not about problems in execution, it's about expression.
:
: [EMAIL PROTECTE
Juerd wrote:
Rob Kinyon skribis 2005-11-23 11:58 (-0500):
I don't use 0..$n-1 very often. I use 0..$#arr most often.
Good point. Doesn't ^5 encourage [EMAIL PROTECTED] too much? After all, we
should
write what we mean, instead of something that happens to evaluate to the
same list. We mean
Ruud H.G. van Tol skribis 2005-11-23 19:03 (+0100):
> > Doesn't ^5 encourage [EMAIL PROTECTED] too much?
> Can you explain when that creates a problem?
It's not about problems in execution, it's about expression.
[EMAIL PROTECTED] returns the *number of elements*, not the index of the last
elemen
Juerd:
> Doesn't ^5 encourage [EMAIL PROTECTED] too much?
Can you explain when that creates a problem?
Maybe someone doing
for ([EMAIL PROTECTED])->$i { say @foo[$i] }
in stead of
say for @foo
> After all, we should
> write what we mean, instead of something that happens
> to evaluate to t
On Wed, Nov 23, 2005 at 06:21:56PM +0100, Juerd wrote:
: Larry Wall skribis 2005-11-23 9:19 (-0800):
: > ^5.each { say }
:
: Without colon?
Yeah, that one doesn't work a couple of way. Unfortunately .each still
binds tighter than ^ too. So it'd have to be:
(^5).each: { say }
unless w
On Wed, Nov 23, 2005 at 11:55:35AM -0500, Matt Fowles wrote:
: I think using C< ..5 > to mean (0, 1, 2, 3, 4) would be a more
: sensible option. Makes sense to me at least.
That doesn't derive well from any of:
..
^..
..^
^..^
If the rule is "you can omit the 0", then it's ..^5
On Wed, Nov 23, 2005 at 11:58:23AM -0500, Rob Kinyon wrote:
: Here's an issue - if ^$x would be one($x), then what will [EMAIL PROTECTED]
be? To
: me, that seems like it should be one(@x), which is entirely useful.
: Except, if I try and use it as [EMAIL PROTECTED] (which, to me, would be
useful)
Larry Wall skribis 2005-11-23 9:19 (-0800):
> ^5.each { say }
Without colon?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
On Wed, Nov 23, 2005 at 02:23:51PM +0100, Ruud H.G. van Tol wrote:
: Larry Wall:
:
: > for ^5 { say } # 0, 1, 2, 3, 4
:
: The 'for' can go if a list (and also an array) would imply looping, when
: it is positioned next to a block:
:
: a. say (0..4);
: b. { say; say } (0..4);
: c. (0..4)
Rob Kinyon skribis 2005-11-23 11:58 (-0500):
> I don't use 0..$n-1 very often. I use 0..$#arr most often.
Good point. Doesn't ^5 encourage [EMAIL PROTECTED] too much? After all, we
should
write what we mean, instead of something that happens to evaluate to the
same list. We mean to use indexes,
Matt Fowles skribis 2005-11-23 11:55 (-0500):
> I think using C< ..5 > to mean (0, 1, 2, 3, 4) would be a more
> sensible option. Makes sense to me at least.
.. as a unary is uncomfortable, because of the different whitespace
styles people use with this operator. I personally use both "0..15"
an
On 11/23/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> On 11/23/05, Rob Kinyon <[EMAIL PROTECTED]> wrote:
> > On 11/22/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> > >
> > > for ^5 { say } # 0, 1, 2, 3, 4
> >
> > I read this and I'm trying to figure out why P6 needs a unary operator
> > for some
Luke~
On 11/23/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> On 11/23/05, Rob Kinyon <[EMAIL PROTECTED]> wrote:
> > On 11/22/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> > >
> > > for ^5 { say } # 0, 1, 2, 3, 4
> >
> > I read this and I'm trying to figure out why P6 needs a unary operator
> > f
On Wed, 23 Nov 2005, Ruud H.G. van Tol wrote:
for ^5 { say } # 0, 1, 2, 3, 4
The 'for' can go if a list (and also an array) would imply looping, when
it is positioned next to a block:
a. say (0..4);
b. { say; say } (0..4);
I'm not really sure: while I like it for its conciseness -and
Larry Wall:
> for ^5 { say } # 0, 1, 2, 3, 4
The 'for' can go if a list (and also an array) would imply looping, when
it is positioned next to a block:
a. say (0..4);
b. { say; say } (0..4);
c. (0..4) { say; say }
d. @{0..4} { say; say }
(etc.)
b. now produces 2 lines with 01234 (in p
On 11/23/05, Rob Kinyon <[EMAIL PROTECTED]> wrote:
> On 11/22/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> >
> > for ^5 { say } # 0, 1, 2, 3, 4
>
> I read this and I'm trying to figure out why P6 needs a unary operator
> for something that is an additional character written the more legible
> w
On 11/22/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> What tipped me over the edge, however, is that I want ^$x back for a
> unary operator that is short for 0..^$x, that is, the range from 0
> to $x - 1. I kept wanting such an operator in revising S09. It also
> makes it easy to write
>
> for
I'm changing my mind about type sigils. After playing around with ^
for a while, I find it's useful only in signatures and declarations,
and I'm generally forced to omit it when using it within inner
declarations, or it would redeclare the type. Taking that together
with the fact that it installs
45 matches
Mail list logo
