I've never figured out why this intuitive syntax does not work. It should,
because doing $# inside the subscripts is really awkward, and I don't see
any ambguity here. Either that you have to use @a[3 .. scalar(@a) - 1 ].
Is there an easier way to do this?
Thanks,
-Clint
On Thu, 08 Nov 2007 17:25:48 -0600, Clint Olsen
>I've never figured out why this intuitive syntax does not work. It should,
>because doing $# inside the subscripts is really awkward, and I don't see
>any ambguity here. Either that you have to use @a[3 .. scalar(@a) - 1 ].
>
>Is there an easier way to do this?
Basically, no. But you don't need the explicit scalar():
@a[3 .. (@a - 1)]
would do. But since we're talking about an index, $#a would be even
better:
@a[3 .. $#a]
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^
On 2007-11-08, Michele Dondi
> Basically, no. But you don't need the explicit scalar():
>
> @a[3 .. (@a - 1)]
>
> would do. But since we're talking about an index, $#a would be even
> better:
>
> @a[3 .. $#a]
This doesn't work for array references. How can I perform the same ($#) on
an array reference?
I got this when trying to:
DB<10> x $#{@$_}
Bizarre copy of ARRAY in leave at (eval
76)[/nfs/pdx/disks/pdx_otools/lib/perl5/5.8.5/perl5db.pl:620 ] line 2.
And $_ is an array reference.
-Clint
[A complimentary Cc of this posting was sent to
Clint Olsen
> I've never figured out why this intuitive syntax does not work. It should,
> because doing $# inside the subscripts is really awkward, and I don't see
> any ambguity here.
Me too. 3..-1 INAMBIGUOUSLY returns an empty list.
Hope this helps,
Ilya
On 2007-11-08, Clint Olsen
> I've never figured out why this intuitive syntax does not work. It should,
> because doing $# inside the subscripts is really awkward, and I don't see
> any ambguity here. Either that you have to use @a[3 .. scalar(@a) - 1 ].
I think I figured out why this doesn't work the way I expected. Since the
'..' operator creates a list (series) from the left value to the right, it
doesn't make sense to do this from a valid index to -1.
And I also through experimentation figured out why the array reference
doesn't work. The syntax appears to be:
$#$_
Where $_ is an array reference. I can't explain why this works however
based on my knowledge of perl and references...
-Clint
On Nov 8, 8:34 pm, Clint Olsen
> And I also through experimentation figured out why the array
> reference doesn't work. The syntax appears to be:
>
> $#$_
>
> Where $_ is an array reference. I can't explain why this works
> however based on my knowledge of perl and references...
The rule is that you take the reference, and treat the reference as
the "name" of the array. Then every other operation is exactly the
same as it is for a normal array.
Normal array:
@foo - "name" of array is foo.
Normal array element:
$foo[0]
Normal array slice:
@foo[0..5];
Normal array last index:
$#foo
Array reference:
$ref - "name" of array is $ref.
Array reference element:
$$ref[0]
Array reference slice:
@$ref[0..5]
Array reference last index:
$#$ref
Paul Lalli
Clint Olsen
> The syntax appears to be:
>
> $#$_
>
> Where $_ is an array reference. I can't explain why this works however
> based on my knowledge of perl and references...
Simply apply "Use Rule 1" from perlreftut.pod.
I like to do it in 3 steps:
1) $#a # pretend it is a normal array
2) $#{ } # replace the name with a block
3) $#{ $_ } # fillin the block with something that returns
# the appropriate type of reference (array in this case)
If what is in the block is a simple, standalone scalar, then you
are allowed to leave out the curly braces:
$#$_
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
On Thu, 08 Nov 2007 19:15:43 -0600,
Clint Olsen
> On 2007-11-08, Michele Dondi
>> Basically, no. But you don't need the explicit scalar():
>>
>> @a[3 .. (@a - 1)]
>>
>> would do. But since we're talking about an index, $#a would be even
>> better:
>>
>> @a[3 .. $#a]
>
> This doesn't work for array references. How can I perform the same ($#) on
> an array reference?
my $ra = \@a;
my $last_index = $#$ra;
Martien
--
|
Martien Verbruggen | I think there is a world market for maybe
| five computers. -- Thomas Watson, chairman of
| IBM, 1943
On Thu, 08 Nov 2007 19:15:43 -0600, Clint Olsen
>This doesn't work for array references. How can I perform the same ($#) on
>an array reference?
>
>I got this when trying to:
>
>DB<10> x $#{@$_}
>Bizarre copy of ARRAY in leave at (eval
>76)[/nfs/pdx/disks/pdx_otools/lib/perl5/5.8.5/perl5db.pl:62 0] line 2.
>
>And $_ is an array reference.
It does work. Of course you're not dereferencing the right way, AND it
must be a NAMED reference.
pilsner:~ [11:22:48]$ perl -le '$a=[1..5];print @$a[3..$#$a]'
45
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^
On Thu, 08 Nov 2007 19:34:05 -0600, Clint Olsen
>$#$_
>
>Where $_ is an array reference. I can't explain why this works however
>based on my knowledge of perl and references...
It's kind of a corner case. The whole $#array thing is rather ugly
IMHO. Perl 6 will have suitable methods instead.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^
On Nov 9, 5:22 am, Michele Dondi
> It does work. Of course you're not dereferencing the right way,
> AND it must be a NAMED reference.
Says who?
$ perl -le'print $#{[qw/a b c d e/]}'
4
Paul Lalli
On Fri, 09 Nov 2007 03:37:50 -0800, Paul Lalli
wrote:
>> It does work. Of course you're not dereferencing the right way,
>> AND it must be a NAMED reference.
>
>Says who?
>
>$ perl -le'print $#{[qw/a b c d e/]}'
>4
I *said* that! /me stands corrected. But... err well, it's kind of
unlikely that one may want say
@{[qw/a b c d e/]}[3..$#{[qw/a b c d e/]}]
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^
On Nov 9, 9:09 am, Michele Dondi
> On Fri, 09 Nov 2007 03:37:50 -0800, Paul Lalli
> wrote:
>
> >> It does work. Of course you're not dereferencing the right way,
> >> AND it must be a NAMED reference.
>
> >Says who?
>
> >$ perl -le'print $#{[qw/a b c d e/]}'
> >4
>
> I *said* that! /me stands corrected. But... err well, it's kind of
> unlikely that one may want say
>
> @{[qw/a b c d e/]}[3..$#{[qw/a b c d e/]}]
Agreed, but I could conceive of a slightly more likely requirement:
print "Enter two numbers:\n";
my ($x, $y) = split / /, <>;
my @skip_three = @{[$x .. $y]}[3..$#{[$x .. $y]}];
Ugly as sin, and I would never do it like that (I would just add 3 to
$x).... but it is possible.
Paul Lalli
On Fri, 9 Nov 2007 01:23:09 +0000 (UTC) Ilya Zakharevich
IZ> [A complimentary Cc of this posting was sent to
IZ> Clint Olsen
IZ>
>> I've never figured out why this intuitive syntax does not work. It should,
>> because doing $# inside the subscripts is really awkward, and I don't see
>> any ambguity here.
IZ> Me too. 3..-1 INAMBIGUOUSLY returns an empty list.
Well obviously in a general context, but Perl semantics for array
offsets also specifically know about negative numbers, so this is a
conflict between two DWIM modes (and I think the array offset DWIM mode
should win). I actually did this just the other day (using $#array as
the last offset) and thought "hmm, wouldn't it be nice to use -1" so
Clint's question makes sense.
I don't see why it's not possible, *within the context of an array
slice*, to override the .. and ... operators to replace negative numbers
with the corresponding array offsets. It might break existing code, but
it really does make sense to users, so at least as a pragma it would be
nice. Plus, the Perl golf possibilities are really good :)
Ted
On Fri, 09 Nov 2007 06:59:38 -0800, Paul Lalli
wrote:
>> @{[qw/a b c d e/]}[3..$#{[qw/a b c d e/]}]
>
>Agreed, but I could conceive of a slightly more likely requirement:
>
>print "Enter two numbers:\n";
>my ($x, $y) = split / /, <>;
>my @skip_three = @{[$x .. $y]}[3..$#{[$x .. $y]}];
Yep, slightly more reasonable. I don't like repetition, though and if
I really had to do it "like that" I'd probably do
my @skip_three = map @$_[3..$#$_], [$x .. $y];
# modulo typos
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^
On Fri, 09 Nov 2007 09:48:21 -0600, Ted Zlatanov
wrote:
>I don't see why it's not possible, *within the context of an array
>slice*, to override the .. and ... operators to replace negative numbers
>with the corresponding array offsets. It might break existing code, but
>it really does make sense to users, so at least as a pragma it would be
>nice. Plus, the Perl golf possibilities are really good :)
Personally I would find it terribly ugly. Perhaps some other kind of
shortcut altogether.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^
Paul Lalli
> On Nov 9, 5:22 am, Michele Dondi
> > It does work. Of course you're not dereferencing the right way,
> > AND it must be a NAMED reference.
>
> Says who?
>
> $ perl -le'print $#{[qw/a b c d e/]}'
> 4
OK, now put that construct in the slice.
This works, but it is pretty much cheating as you have two array references
rather than one:
perl -le 'print (qw/a b c d e/)[3..$#{[qw/a b c d e/]}]'
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
Clint Olsen
> I've never figured out why this intuitive syntax does not work. It
> should, because doing $# inside the subscripts is really awkward, and I
> don't see any ambguity here.
It can do either what you (and I) think it should do, or it can do what it
currently *does* do (which is also what it currently does, and presumably
would still do under your proposed change, outside of the slice context).
So that is two things it might reasonably by expected to do. An ambiguity.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
[A complimentary Cc of this posting was sent to
Ted Zlatanov
> IZ> Me too. 3..-1 INAMBIGUOUSLY returns an empty list.
>
> Well obviously in a general context, but Perl semantics for array
> offsets also specifically know about negative numbers, so this is a
> conflict between two DWIM modes (and I think the array offset DWIM mode
> should win).
As far as I know, there is no DWIM involved. There are two operators,
both fully-and-simply defined; array offset (which is defined for
-$#-1..$#), and range. You REALLY want the result of an operator be
dependent on argument of which operator it is?
IMO, Perl evolution should go in DECREASING number of DWIM stuff (at
least, as a pragma), not increasing it. (Currently, the probability
of an experienced Perl programmer to predict a result of running
*simple* Perl code is close to 0 - unless one severely binds oneself
via coding style discipline. Too many un-/half-documented special
cases...)
> I actually did this just the other day (using $#array as
> the last offset) and thought "hmm, wouldn't it be nice to use -1" so
> Clint's question makes sense.
I do it myself often too. It does not make it a lesser evil.
Hope this helps,
Ilya
On 2007-11-09, Ilya Zakharevich
> As far as I know, there is no DWIM involved. There are two operators,
> both fully-and-simply defined; array offset (which is defined for
> -$#-1..$#), and range. You REALLY want the result of an operator be
> dependent on argument of which operator it is?
In the spirit of Perl and evaluations based on usage context, I don't see
this as a farfetched thing. Hey, Perl invented the concept of context, not
me :)
-Clint
On Fri, 9 Nov 2007 18:29:39 +0000 (UTC), Ilya Zakharevich
>IMO, Perl evolution should go in DECREASING number of DWIM stuff (at
>least, as a pragma), not increasing it. (Currently, the probability
>of an experienced Perl programmer to predict a result of running
>*simple* Perl code is close to 0 - unless one severely binds oneself
>via coding style discipline. Too many un-/half-documented special
>cases...)
Well there are two conflicting POVs that should be balanced:
(i) a vector space is a relatively simple algebraic structure. A
programming language with (largely) orthogonal features is nice in
that it makes for the principle of least surprise;
(ii) a manifold (e.g.) is admittedly a richer structure than a vector
space. Perl often deviates from orthogonality for the sake of
dwimmeries. Dwimmeries often have to do with psychological perception
and linguistic issues which in turn often deviate from linearity.
As Perl is now is mostly satisfactory, and indeed I would dread upon
ranges behaving as suggested within subscripts.
The big challenge of Perl 6 is to achieve a high degree of dwimmery
while staying at the same time consistent and orthogonal. It aims, in
other words, at bringing dwimmery into the basic "vector space
structure". Well, sort of.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^
On Fri, 09 Nov 2007 12:40:16 -0600, Clint Olsen
>> As far as I know, there is no DWIM involved. There are two operators,
>> both fully-and-simply defined; array offset (which is defined for
>> -$#-1..$#), and range. You REALLY want the result of an operator be
>> dependent on argument of which operator it is?
>
>In the spirit of Perl and evaluations based on usage context, I don't see
>this as a farfetched thing. Hey, Perl invented the concept of context, not
>me :)
"Subscript context"? No, kinda too much for me... Even worse,
subscripting strongly reminds me of mathematical usage. A range of
3..-1 returning 3..$#array reminds me of a mathematical nightmare.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^
On 2007-11-09, Michele Dondi
> "Subscript context"? No, kinda too much for me... Even worse,
> subscripting strongly reminds me of mathematical usage. A range of 3..-1
> returning 3..$#array reminds me of a mathematical nightmare.
Well, I was thinking more '..' in an array/list context, but yeah.
-Clint
On Fri, 09 Nov 2007 21:17:54 +0100 Michele Dondi
MD> "Subscript context"? No, kinda too much for me... Even worse,
MD> subscripting strongly reminds me of mathematical usage. A range of
MD> 3..-1 returning 3..$#array reminds me of a mathematical nightmare.
Well, actually I would argue vehemently that the above should return 3,
2, 1, 0, -1 in regular context. I think Perl, normally a clever
language, is not clever on this. Ask any child what 3..-1 should
generate as a sequence, and they won't say "empty list."
If 3..-1 returned a downward range, it would be trivial to look at the
array slice offsets, check if the last number is negative, and do the
right thing for that case. But instead, we get the empty list because
... only counts *up* and that causes the subsequent problems. But I
realize changing .. is a completely impossible thing, and at least half
the Perl coders will disagree with me, so I'm only suggesting a
subscript context DWIMmery. That's slightly less anathema I think.
Ted
On Fri, 9 Nov 2007 18:29:39 +0000 (UTC) Ilya Zakharevich
IZ> [A complimentary Cc of this posting was sent to
IZ> Ted Zlatanov
IZ>
IZ> Me too. 3..-1 INAMBIGUOUSLY returns an empty list.
>>
>> Well obviously in a general context, but Perl semantics for array
>> offsets also specifically know about negative numbers, so this is a
>> conflict between two DWIM modes (and I think the array offset DWIM mode
>> should win).
IZ> As far as I know, there is no DWIM involved. There are two operators,
IZ> both fully-and-simply defined; array offset (which is defined for
IZ> -$#-1..$#), and range. You REALLY want the result of an operator be
IZ> dependent on argument of which operator it is?
Yes, I think I do. I could be wrong in wanting it, but it feels right.
It's like a chocolate donut, only much more abstract :)
IZ> IMO, Perl evolution should go in DECREASING number of DWIM stuff (at
IZ> least, as a pragma), not increasing it. (Currently, the probability
IZ> of an experienced Perl programmer to predict a result of running
IZ> *simple* Perl code is close to 0 - unless one severely binds oneself
IZ> via coding style discipline. Too many un-/half-documented special
IZ> cases...)
I agree. And yet, I'm tempted by chocolate.
>> I actually did this just the other day (using $#array as
>> the last offset) and thought "hmm, wouldn't it be nice to use -1" so
>> Clint's question makes sense.
IZ> I do it myself often too. It does not make it a lesser evil.
No, but it does tell you something about how people think. Intuition
often contradicts logic and consistency.
Ted
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Michele Dondi
> As Perl is now is mostly satisfactory
Could not agree less. Perl IS nighmarish NOW.
> The big challenge of Perl 6 is to achieve a high degree of dwimmery
> while staying at the same time consistent and orthogonal. It aims, in
> other words, at bringing dwimmery into the basic "vector space
> structure". Well, sort of.
What I saw of Perl6 is much much worse than even Perl5.
Hope this helps,
Ilya
[A complimentary Cc of this posting was sent to
Ted Zlatanov
> IZ> As far as I know, there is no DWIM involved. There are two operators,
> IZ> both fully-and-simply defined; array offset (which is defined for
> IZ> -$#-1..$#), and range. You REALLY want the result of an operator be
> IZ> dependent on argument of which operator it is?
> Yes, I think I do. I could be wrong in wanting it, but it feels right.
When I raised this issue on p5-p about a decade ago, (IIRC) at
first I was arguing on your side. Now, after thinking about it for
quite some time, my position is the opposite.
Make your own conclusions from this...
> It's like a chocolate donut, only much more abstract :)
> IZ> IMO, Perl evolution should go in DECREASING number of DWIM stuff (at
> IZ> least, as a pragma), not increasing it. (Currently, the probability
> IZ> of an experienced Perl programmer to predict a result of running
> IZ> *simple* Perl code is close to 0 - unless one severely binds oneself
> IZ> via coding style discipline. Too many un-/half-documented special
> IZ> cases...)
>
> I agree. And yet, I'm tempted by chocolate.
This is what pragmas are about. IIRC, in the end of 90's, I was
advocating something like
use kiss;
which would prohibit all hard-to-document and all non-orthogonal
constructs (intended for large projects and teamworks). Nobody was
interested enough, and, IIRC, my pilot implementations were not
accepted.
> IZ> I do it myself often too. It does not make it a lesser evil.
> No, but it does tell you something about how people think. Intuition
> often contradicts logic and consistency.
This is not the reason to follow intuition. Intuition has its place;
one-liners have their place. Not everything should be written in a
style appropriate for 1-liners.
Hope this helps,
Ilya
[A complimentary Cc of this posting was sent to
Ted Zlatanov
> On Fri, 09 Nov 2007 21:17:54 +0100 Michele Dondi
> Well, actually I would argue vehemently that the above should return 3,
> 2, 1, 0, -1 in regular context.
And you would be wrong in this...
> I think Perl, normally a clever language, is not clever on this.
> Ask any child what 3..-1 should generate as a sequence, and they
> won't say "empty list."
IMO, child's opinion should not have very high priority in design of
programming languages. Remember how late the concept of 0 made it
into the common culture?
Hint: your proposal breaks the fundamental proportion:
5..7 ==> 5 6 7
5..6 ==> 5 6
5..5 ==> 5
5..4 ==> ???
> If 3..-1 returned a downward range, it would be trivial to look at the
> array slice offsets, check if the last number is negative, and do the
> right thing for that case.
I see, you want YET ANOTHER "right thing". How nice of you... And
what @a[5,2] should return, in your opinion?
Hope this helps,
Ilya
On Sat, 10 Nov 2007 02:48:40 +0000, Ilya Zakharevich wrote:
> [A complimentary Cc of this posting was sent to Ted Zlatanov
>
>> On Fri, 09 Nov 2007 21:17:54 +0100 Michele Dondi
>>
>
>> Well, actually I would argue vehemently that the above should return 3,
>> 2, 1, 0, -1 in regular context.
>
> And you would be wrong in this...
>
>> I think Perl, normally a clever language, is not clever on this. Ask
>> any child what 3..-1 should generate as a sequence, and they won't say
>> "empty list."
>
> IMO, child's opinion should not have very high priority in design of
> programming languages. Remember how late the concept of 0 made it into
> the common culture?
>
> Hint: your proposal breaks the fundamental proportion:
>
> 5..7 ==> 5 6 7
> 5..6 ==> 5 6
> 5..5 ==> 5
> 5..4 ==> ???
>
Yes, but how about
for (3 .. 1) {
...
}
It would be very useful to have that count back, and it would be very
intuitive imo.
M4
Ted Zlatanov schreef:
> I don't see why it's not possible, *within the context of an array
> slice*, to override the .. and ... operators to replace negative
> numbers with the corresponding array offsets.
Another DWIM-candidate:
being able to write
return \%data{@keys}
in stead of (the copying)
my %tmp;
@tmp{@keys} = @data{@keys};
return \%tmp;
# ;)
(on p5p, Josh Jore came up with:
return sub { \@_ }->( @data{@keys} );
)
--
Affijn, Ruud
"Gewoon is een tijger."
On Fri, 09 Nov 2007 17:02:12 -0600, Clint Olsen
>> subscripting strongly reminds me of mathematical usage. A range of 3..-1
>> returning 3..$#array reminds me of a mathematical nightmare.
>
>Well, I was thinking more '..' in an array/list context, but yeah.
Well, that would be... quite about anywhere, since C<..> in scalar
context is an entirely different beast. And since you mention *list*
context (there is not *really* anything like "array" context in Perl)
what meaning should e.g.
print 3..-2;
print from your pov?
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^
On Fri, 09 Nov 2007 17:09:38 -0600, Ted Zlatanov
wrote:
>Well, actually I would argue vehemently that the above should return 3,
>2, 1, 0, -1 in regular context. I think Perl, normally a clever
>language, is not clever on this. Ask any child what 3..-1 should
>generate as a sequence, and they won't say "empty list."
Well, I may be a strange animal but it is very unintuitive to me.
3..-1 very directly reads in my mind like "the sequence of integers n
such that 3<=n<=-1", which happens to be empty, period.
Perhaps, at least in this little thing I'm not a child anymore! ;)
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^
On Sat, 10 Nov 2007 10:19:19 +0100, Martijn Lievaart
>Yes, but how about
>
> for (3 .. 1) {
> ...
> }
>
>It would be very useful to have that count back, and it would be very
>intuitive imo.
No, it wouldn't, reverse() is what one wants. Admittedly, it is
slightly long to write down. Perhaps one issue is that ".." is
symmetric but represents a "directed" thingie. Of course the arrow is
already taken for something else but some kind of arrow would be
better suited for this semantics, better conveying the significance of
"upto" and "downto". Thus
(imagine some actually suitable symbol in between.)
3 ^ 1; # empty
1 ^ 3; # 1,2,3
3 v 1; # 3,2,1
1 v 3; # empty
and if one really really wanted, then perhaps
$n x $m; # $n < $m ? $n ^ $m : $n v $m
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^
On Sat, 10 Nov 2007 02:34:15 +0000 (UTC), Ilya Zakharevich
>> The big challenge of Perl 6 is to achieve a high degree of dwimmery
>> while staying at the same time consistent and orthogonal. It aims, in
>> other words, at bringing dwimmery into the basic "vector space
>> structure". Well, sort of.
>
>What I saw of Perl6 is much much worse than even Perl5.
It may be, but in other respects: certainly ad hoc deviations from
orthogonality have been reduced by several orders of magnitude. It is
by all means more consistent and regular. Whether it is better or
worse, more beautiful or uglier, spicy or sweet and so on, are
entirely different matters.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^
On Sat, 10 Nov 2007 02:42:35 +0000 (UTC), Ilya Zakharevich
>When I raised this issue on p5-p about a decade ago, (IIRC) at
>first I was arguing on your side. Now, after thinking about it for
>quite some time, my position is the opposite.
Smart persons are able to change their mind, in fact.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^
On Sat, 10 Nov 2007 10:24:23 +0100, "Dr.Ruud"
>Another DWIM-candidate:
>
>being able to write
>
> return \%data{@keys}
Well, without even mentioning the referencing thing, first one useful
dwimmery would be the ability to slice a hash like that.
my %sliced=%data{@keys};
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^
_
Martijn Lievaart (m@rtij.nl.invlalid) wrote on VCLXXXIV September
MCMXCIII in
\\ On Sat, 10 Nov 2007 02:48:40 +0000, Ilya Zakharevich wrote:
\\
\\ > [A complimentary Cc of this posting was sent to Ted Zlatanov
\\ >
\\ >> On Fri, 09 Nov 2007 21:17:54 +0100 Michele Dondi
\\ >>
\\ >
\\ >> Well, actually I would argue vehemently that the above should return 3,
\\ >> 2, 1, 0, -1 in regular context.
\\ >
\\ > And you would be wrong in this...
\\ >
\\ >> I think Perl, normally a clever language, is not clever on this. Ask
\\ >> any child what 3..-1 should generate as a sequence, and they won't say
\\ >> "empty list."
\\ >
\\ > IMO, child's opinion should not have very high priority in design of
\\ > programming languages. Remember how late the concept of 0 made it into
\\ > the common culture?
\\ >
\\ > Hint: your proposal breaks the fundamental proportion:
\\ >
\\ > 5..7 ==> 5 6 7
\\ > 5..6 ==> 5 6
\\ > 5..5 ==> 5
\\ > 5..4 ==> ???
\\ >
\\
\\ Yes, but how about
\\
\\ for (3 .. 1) {
\\ ...
\\ }
\\
\\ It would be very useful to have that count back, and it would be very
\\ intuitive imo.
Yeah, it would be sometimes be useful to have it count back. Often
though, it's also very useful to have 3 .. 1 return an empty list.
I don't know which one is more useful. But that doesn't matter; it's
too late to change. Even if there's more benefit that 3 .. 1 'counts
backwards' than 3 .. 1 being an empty list, the disadvantage of
changing the meaning (and hence having lots of potential code that
breaks; it's not that .. is an uncommon operation) far outweights
any possible benefit.
Besides, we already have 'reverse' to count backwards. And it's pretty
simple to write a sub that returns an ascending or descending range depending
on the order of the arguments (untested):
sub range ($$) {
return $_ [0] .. $_ [1] if $_ [0] <= $_ [1];
return reverse $_ [1] .. $_ [0];
}
for (range 3, 1) {
...
}
Note however that having .. count backwards if the second argument
is smaller than the first, does NOT solve the slice issue.
@array = qw [one two three four five six];
@array [3 .. $#array]; # 'four', 'five', 'six'; indented value
# of @array [3 .. -1].
@array [3 .. -1] # 'four', 'three', 'two', 'one', 'six';
# value if .. counts backwards.
Abigail
--
perl -le 's[$,][join$,,(split$,,($!=85))[(q[0006143730380126152532042 307].
q[41342211132019313505])=~m[..]g]]e and y[yIbp][HJkP] and print'
On Sat, 10 Nov 2007 02:48:40 +0000 (UTC) Ilya Zakharevich
IZ> [A complimentary Cc of this posting was sent to
IZ> Ted Zlatanov
IZ>
>> I think Perl, normally a clever language, is not clever on this.
>> Ask any child what 3..-1 should generate as a sequence, and they
>> won't say "empty list."
IZ> IMO, child's opinion should not have very high priority in design of
IZ> programming languages.
OK, ask anyone at all what "3 .. -1" should be, mathematician or not,
that's not a Perl programmer. The design of Perl 5 chose consistency
(.. always counts up and generates an empty list if it can't) over DWIM
(count from x to y, either up or down) here.
I don't think the DWIM mode is wrong, as evidenced by the percentage of
people that would tell you it's what they expect (informal poll on 5
people by me: 100%). It would break code, though, so I don't propose
that it be the default.
IZ> Hint: your proposal breaks the fundamental proportion:
IZ> 5..7 ==> 5 6 7
IZ> 5..6 ==> 5 6
IZ> 5..5 ==> 5
IZ> 5..4 ==> ???
You see .. as a forward vector on the integer number line. I think the
vector could point down as well:
5..4 ==> 5 4
5..1 ==> 5 4 3 2 1
1..-1 ==> 1 0 -1
Again, this is not my overactive imagination, it's what people expect.
>> If 3..-1 returned a downward range, it would be trivial to look at the
>> array slice offsets, check if the last number is negative, and do the
>> right thing for that case.
IZ> I see, you want YET ANOTHER "right thing". How nice of you... And
IZ> what @a[5,2] should return, in your opinion?
That's irrelevant. My point is:
1) in @array[x..y] make the .. operator count down IFF y is negative
("subscript context"). As an alternative, make it count down everywhere
with a pragma, or make it count down in subscript context with a pragma.
2) any negative subscripts refer to the last-minus-y offset (which is
already the case).
So the change is only to .. and entirely optional. Another operator,
some Unicode character, could be used instead of .. if you think it's a
better choice.
Ted
On Sat, 10 Nov 2007 12:08:43 +0100 Michele Dondi
MD> On Sat, 10 Nov 2007 10:19:19 +0100, Martijn Lievaart
MD>
>> for (3 .. 1)
>> It would be very useful to have that count back, and it would be very
>> intuitive imo.
MD> No, it wouldn't, reverse() is what one wants.
No, it's what Perl 5 wants and the programmer has to satisfy it. People
want the intuitive range, up or down.
Ted
On 10 Nov 2007 12:34:59 GMT Abigail
A> I don't know which one is more useful. But that doesn't matter; it's
A> too late to change. Even if there's more benefit that 3 .. 1 'counts
A> backwards' than 3 .. 1 being an empty list, the disadvantage of
A> changing the meaning (and hence having lots of potential code that
A> breaks; it's not that .. is an uncommon operation) far outweights
A> any possible benefit.
That's why my proposal was with a pragma and only in subscript context
(although in global context it would work too).
A> Note however that having .. count backwards if the second argument
A> is smaller than the first, does NOT solve the slice issue.
A> @array = qw [one two three four five six];
A> @array [3 .. $#array]; # 'four', 'five', 'six'; indented value
A> # of @array [3 .. -1].
A> @array [3 .. -1] # 'four', 'three', 'two', 'one', 'six';
A> # value if .. counts backwards.
Ah, you're right, I wasn't thinking. So counting down is not the answer
(though it makes intuitive sense). .. in subscript context would have
to replace -x with the corresponding offset. The resulting mess is not
DWIM, so consider my arguments crap :)
Ted
On Sat, 10 Nov 2007 12:17:37 +0100 Michele Dondi
MD> On Sat, 10 Nov 2007 10:24:23 +0100, "Dr.Ruud"
MD>
>> Another DWIM-candidate:
>>
>> being able to write
>>
>> return \%data{@keys}
MD> Well, without even mentioning the referencing thing, first one useful
MD> dwimmery would be the ability to slice a hash like that.
MD> my %sliced=%data{@keys};
A "slice" operator? Maybe look for a Unicode "knife" symbol? :)
Ted
On Sat, 10 Nov 2007 09:09:19 -0600, Ted Zlatanov
wrote:
>On Sat, 10 Nov 2007 12:08:43 +0100 Michele Dondi
>
>MD> On Sat, 10 Nov 2007 10:19:19 +0100, Martijn Lievaart
>MD>
>
>>> for (3 .. 1)
>>> It would be very useful to have that count back, and it would be very
>>> intuitive imo.
>
>MD> No, it wouldn't, reverse() is what one wants.
>
>No, it's what Perl 5 wants and the programmer has to satisfy it. People
>want the intuitive range, up or down.
No people who find the range intuitive that way want it that way. To
me and someone else it is counter-intuitive. I'm not a mathematician
nor do I have extraordinary mathematical skills, but mathematics is
*very* intuitive to me. That other use is confusing and inconsistent.
Perhaps because I have some more experience than you with
combinatorics where e.g. a sum from n to m where n>m is naturally
null. If it were to have "your" meaning, it would make calculations
terribly clumsy. Your "intuitive" idea is more that of a *segment*
than a range, but I don't see it as extremely useful unless there
where three different operators (or one operator with suitable
adverbs, but we don't have adverbs in Perl 5 yet) with the semanticts
of respectively "upto", "downto", "between".
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^
On Sat, 10 Nov 2007 09:16:28 -0600, Ted Zlatanov
wrote:
>Ah, you're right, I wasn't thinking. So counting down is not the answer
>(though it makes intuitive sense). .. in subscript context would have
>to replace -x with the corresponding offset. The resulting mess is not
>DWIM, so consider my arguments crap :)
say "Whoa, at least!"; # just kidding ;)
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^
On Sat, 10 Nov 2007 09:17:37 -0600, Ted Zlatanov
wrote:
>MD> my %sliced=%data{@keys};
>
>A "slice" operator? Maybe look for a Unicode "knife" symbol? :)
We're not ready yet for unicode operators. We have to wait for 6. And
call me old-fashioned, but I think I would often use the ascii
equivalent operators most of the times with it too. OTOH I don't see
that we need a special operator at all since the above syntax seems
fine, except that currently generates an error. Of course some p5p'er
may explain that in fact it's *not* fine, e.g. not compatible with...
well anything else.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^
Martijn Lievaart
news:pan.2007.11.10.09.17.10@rtij.nl.invlalid:
> On Sat, 10 Nov 2007 02:48:40 +0000, Ilya Zakharevich wrote:
....
>> Hint: your proposal breaks the fundamental proportion:
>>
>> 5..7 ==> 5 6 7
>> 5..6 ==> 5 6
>> 5..5 ==> 5
>> 5..4 ==> ???
>>
>
> Yes, but how about
>
> for (3 .. 1) {
> ...
> }
>
> It would be very useful to have that count back, and it would be very
> intuitive imo.
Really? That would break a lot of my code: Right now, I know that if
$first > $last, the body of the loop:
for my $i ( $first .. $last ) {
will not run so I use that fact.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
clpmisc guidelines:
Martijn Lievaart wrote:
> Yes, but how about
> for (3 .. 1) {...}
> It would be very useful to have that count back, and it would be very
> intuitive imo.
Absolutely not. I at least don't want to have to check explicitely every
single time
if ($start <= $end) {
for ($start .. $end) {...}
} # else do nothing
That would be so nuts
If you want to count down then just use
for (reverse (1..3)) {...}
jue
Michele Dondi
> On Sat, 10 Nov 2007 10:19:19 +0100, Martijn Lievaart
>
>
> >Yes, but how about
> >
> > for (3 .. 1) {
> > ...
> > }
> >
> >It would be very useful to have that count back, and it would be very
> >intuitive imo.
>
> No, it wouldn't, reverse() is what one wants. Admittedly, it is
> slightly long to write down.
It also materializes its list (currently). So
foreach (reverse 1..1e7) {
might not be such a good idea.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
On 10 Nov 2007 17:39:31 GMT, xhoster@gmail.com wrote:
>> No, it wouldn't, reverse() is what one wants. Admittedly, it is
>> slightly long to write down.
>
>It also materializes its list (currently). So
>foreach (reverse 1..1e7) {
>might not be such a good idea.
That's right. Of course we all want lazy list evaluation by default.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^
On Sat, 10 Nov 2007 17:04:02 +0000, A. Sinan Unur wrote:
> Martijn Lievaart
> news:pan.2007.11.10.09.17.10@rtij.nl.invlalid:
>
>> On Sat, 10 Nov 2007 02:48:40 +0000, Ilya Zakharevich wrote:
> ...
>
>>> Hint: your proposal breaks the fundamental proportion:
>>>
>>> 5..7 ==> 5 6 7
>>> 5..6 ==> 5 6
>>> 5..5 ==> 5
>>> 5..4 ==> ???
>>>
>>>
>> Yes, but how about
>>
>> for (3 .. 1) {
>> ...
>> }
>>
>> It would be very useful to have that count back, and it would be very
>> intuitive imo.
>
> Really? That would break a lot of my code: Right now, I know that if
> $first > $last, the body of the loop:
>
> for my $i ( $first .. $last ) {
>
> will not run so I use that fact.
I'm aware of that and I'm not proposing to change this, or anything other.
I was just commenting on what is intuitive for me and what would have
been useful imo. As changing this idiom breaks a lot of code, we cannot
change this.
Besides, your example is a good counterexample where I would expect the
loop not to run if $last<$first. As someone else wrote, to disambiguate
you would need three different operators, upto, downto and between. Well
downto can be done with reverse and upto, but as already shown, that
breaks lazy evaluation. Although it needn't with a sufficiently smart
reverse.
And there is also the fact that this has nothing to do with the original
problem of using negative integers to denote elements from the end.
All this is just academic, perl is perl and we can't change this. It's
just fun to think about it, sharpens the mind and sometimes something
very useful can come from these discussions.
M4
_
xhoster@gmail.com (xhoster@gmail.com) wrote on VCLXXXIV September
MCMXCIII in
@@ Michele Dondi
@@ > On Sat, 10 Nov 2007 10:19:19 +0100, Martijn Lievaart
@@ >
@@ >
@@ > >Yes, but how about
@@ > >
@@ > > for (3 .. 1) {
@@ > > ...
@@ > > }
@@ > >
@@ > >It would be very useful to have that count back, and it would be very
@@ > >intuitive imo.
@@ >
@@ > No, it wouldn't, reverse() is what one wants. Admittedly, it is
@@ > slightly long to write down.
@@
@@ It also materializes its list (currently). So
@@ foreach (reverse 1..1e7) {
@@ might not be such a good idea.
Nope. Which is why we have C-style loops:
for (my $i = 1e7; $i; $i --) { ... }
Abigail
--
perl -wle 'print "Prime" if (1 x shift) !~ /^1?$|^(11+?)\1+$/'
[A complimentary Cc of this posting was sent to
Ted Zlatanov
> IZ> Hint: your proposal breaks the fundamental proportion:
^^^^^^^^^^ progression
> IZ> 5..7 ==> 5 6 7
> IZ> 5..6 ==> 5 6
> IZ> 5..5 ==> 5
> IZ> 5..4 ==> ???
>
> You see .. as a forward vector on the integer number line. I think the
> vector could point down as well:
>
> 5..4 ==> 5 4
As I have shown, this does not allow $n..$n+$count-1 to get $count items.
> 1) in @array[x..y] make the .. operator count down IFF y is negative
> ("subscript context"). As an alternative, make it count down everywhere
> with a pragma, or make it count down in subscript context with a pragma.
I see: you have never used $array[-5..-1] yet...
Hope this helps,
Ilya
On Sat, 10 Nov 2007 17:16:34 +0100 Michele Dondi
MD> On Sat, 10 Nov 2007 09:16:28 -0600, Ted Zlatanov
MD> wrote:
>> The resulting mess is not DWIM, so consider my arguments crap :)
MD> say "Whoa, at least!"; # just kidding ;)
I love admitting I'm wrong. It means I've learned something or seen
things in a new way.
Ted
On Sat, 10 Nov 2007 23:18:08 +0000 (UTC) Ilya Zakharevich
IZ> I see: you have never used $array[-5..-1] yet...
You're right, I haven't used that one. @array[-5..-1] is pretty useful
though, I've used that :)
Ted