[32221] in Perl-Users-Digest
Perl-Users Digest, Issue: 3486 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Aug 31 16:09:47 2011
Date: Wed, 31 Aug 2011 13:09:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 31 Aug 2011 Volume: 11 Number: 3486
Today's topics:
Re: Why does sort return undef in scalar context ? <rweikusat@mssgmbh.com>
Re: Why does sort return undef in scalar context ? <rweikusat@mssgmbh.com>
Re: Why does sort return undef in scalar context ? <nospam-abuse@ilyaz.org>
Re: Why does sort return undef in scalar context ? <willem@toad.stack.nl>
Re: Why does sort return undef in scalar context ? <tadmc@seesig.invalid>
Re: Why does sort return undef in scalar context ? (Randal L. Schwartz)
Re: Why does sort return undef in scalar context ? <willem@toad.stack.nl>
Re: Why does sort return undef in scalar context ? <sreservoir@gmail.com>
Re: Why does sort return undef in scalar context ? <sreservoir@gmail.com>
Re: Why does sort return undef in scalar context ? <rweikusat@mssgmbh.com>
Re: Why does sort return undef in scalar context ? <sreservoir@gmail.com>
Re: Why does sort return undef in scalar context ? <willem@toad.stack.nl>
Re: Why does sort return undef in scalar context ? sln@netherlands.com
Re: Why does sort return undef in scalar context ? <hjp-usenet2@hjp.at>
Re: Why does sort return undef in scalar context ? <rweikusat@mssgmbh.com>
Re: Why does sort return undef in scalar context ? <rweikusat@mssgmbh.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 31 Aug 2011 12:44:36 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <87ippdajq3.fsf@sapphire.mobileactivedefense.com>
pacman@kosh.dhis.org (Alan Curry) writes:
> In article <slrnj5qbk5.pp7.willem@toad.stack.nl>,
> Willem <willem@toad.stack.nl> wrote:
>>Rainer Weikusat wrote:
>>) There is actually at least on similar operation in Perl, namely,
>>) reverse, which also returns a permutation of the input list. In scalar
>>) context, it will concatenate whatever the elements on the list
>>) stringify to and return a reversed string. This seems a little
>>) arbitrary and not really useful in many cases, eg,
>>)
>>) [rw@tear]~ $perl -de 0
>>)
>>) Loading DB routines from perl5db.pl version 1.3
>>) Editor support available.
>>)
>>) Enter h or `h h' for help, or `man perldebug' for more help.
>>)
>>) main::(-e:1): 0
>>) DB<1> print scalar(reverse(\$a, \$b, \$c))
>>) )0efcb38x0(RALACS)0ffcb38x0(RALACS)040db38x0(RALACS
>>
>>Wow that's pretty useless!
>
> But in the simplest case (a single string argument), the behavior of scalar
> reverse is perfectly logical:
>
> $x = "foobar";
> $y = reverse $x;
> say $y;
>
> If a language built for text processing didn't have a reverse-string
> operation, that would be weird.
A 'reverse string' operation which also works in list context had
nevertheless been a better idea, cf
DB<16> p map { reverse $_; } qw(ab bc de)
abbcde
My original idea of the reason for this was that this probably a Perl4
remnant because it seemed to make more sense in a language without
references. But the Perl 4 documentation for reverse actually says
that
reverse(LIST)*
In array context: returns the LIST in reverse order.
In scalar context: returns the first element of LIST with bytes reversed.
------------------------------
Date: Wed, 31 Aug 2011 13:15:45 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <87d3flaia6.fsf@sapphire.mobileactivedefense.com>
Willem <willem@toad.stack.nl> writes:
> Jim Gibson wrote:
> ) I do not think that your use case is valid. It is silly to sort an
> ) array when all you want is the number of elements in the array. The
> ) subroutine that you wrote to do this is not a good example of good
> ) design. That could be why nobody on this groups agrees that what you
> ) want is desirable.
>
> Well, the fact that you call it a subroutine, and not a function, clearly
> shows that you're stuck in the old perl4 days.
I usually prefer the term 'subroutine' because it emphasizes that this
is not a function in the mathematical sense: It doesn't represent an
equivalence relation but (ultimatively) refers to an ordered set of
machine instruction performing a specific task. And I have never used
a version of Perl older than 5.004.
[...]
> )> To recap:
> )> There is a function that does a lot of work and in the end returns a
> )> sorted list of items. Most of the time I am interested in the actual
> )> list, sometimes I just want to know the number of items.
> )>
> )> Because of this oversight, I am forced to implement a workaround involving
> )> 'wantarray', specifically checking the context, instead of just returning
> )> the sorted list, which would have been much cleaner.
> )
> ) This in not an oversight, but a deliberate choice by the language
> ) designer. You are mischaracterizing the situation.
>
> The deliberate choice was made because the language designer didn't see any
> use cases. If there *is* a use case, then that (not seeing a use case) is
> quite literally an oversight.
If sort would return pi in scalar context, that would also be useful
in some specific situations (as would any other value). But there is
no more relation between the function of sort (return a specific
permutation of its arguments) and 3.1415... than there is between
permuting arguments and counting arguments.
[...]
> ) I have another suggestion for what sort could return in scalar context:
> )
> ) true if the array is already in sort, undef otherwise.
>
> Classic perl4 thinking: Let's overload it to do something related,
> but different!
In my opinion, this suggestion would still be a poor choice, but a
more comprehensible one than the 'let it count its arguments' idea.
------------------------------
Date: Wed, 31 Aug 2011 12:20:34 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <slrnj5s9oi.daj.nospam-abuse@panda.math.berkeley.edu>
On 2011-08-29, Willem <willem@toad.stack.nl> wrote:
> Today I got bitten by a very strange bug/feature:
Feature.
Af there were ONE POSSIBLE logical value for it to return in scalar
context, this would be implemented. Given that there are many
possibilities (min? max? # of elts?), the result is one which would
be detected ASAP as an indication of "bad usage scenario". (die()ing
would be yet more convenient, but not backward-compatible.)
Hope this helps,
Ilya
------------------------------
Date: Wed, 31 Aug 2011 12:52:01 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <slrnj5sbjh.ke9.willem@toad.stack.nl>
Rainer Weikusat wrote:
) I usually prefer the term 'subroutine' because it emphasizes that this
) is not a function in the mathematical sense:
You should be worrying more about the definition of 'function' in the
computer sciences, because that's much more closely related to programming.
) It doesn't represent an
) equivalence relation but (ultimatively) refers to an ordered set of
) machine instruction performing a specific task. And I have never used
) a version of Perl older than 5.004.
Even in mathematics, a function doesn't always represent an equivalence
relation. Take lambda calculus, for example.
)> The deliberate choice was made because the language designer didn't see any
)> use cases. If there *is* a use case, then that (not seeing a use case) is
)> quite literally an oversight.
)
) If sort would return pi in scalar context, that would also be useful
) in some specific situations (as would any other value). But there is
) no more relation between the function of sort (return a specific
) permutation of its arguments) and 3.1415... than there is between
) permuting arguments and counting arguments.
Yes there is. If you view sort in a functional-programming way, then
it is: 'array -> sort -> array'. Using an array as a scalar gives
the number of elements. Therefore using the result of sort as a scalar
should give the number of elements as well. Simple logic.
Compare, for example, a completely OO language, where there is a 'list'
class. To get the perl behaviour of number-of-elements, you would simply
implement a convert-to-integer member function, which the language then
automatically calls whenever it has a 'list' but wants an 'integer'.
Now, there is a sort function which takes a 'list' object and returns a
'list' object. It is left as an exercise to figure out what would happen
if you were to use sort() but want the result as an integer.
PS: As far as I can tell from the online docs, it works like this
in Perl6 as well.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Wed, 31 Aug 2011 07:55:04 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <slrnj5sb6e.mle.tadmc@tadbox.sbcglobal.net>
Willem <willem@toad.stack.nl> wrote:
> Jim Gibson wrote:
> ) Any problems with maintenance of your code is more likely going to be
> ) due to poor design.
>
> Why did you feel the need to throw in a gratuitous ad hominem attack ?
It is neither gratuitous nor ad hominem.
It is entirely possible, whether you agree with it or not,
that it *is* a poor design.
Offering an opinion (even if different) is not "gratuitous".
He didn't say that _you_ were bad, he said that your _code_ was bad,
so, not "ad hominem" either...
A criticism of your code is not a criticism of you.
> You do realise that this very comment caused me to dismiss you as a viable
> discussion partner, right ?
You do realise that being unable to acknowledge that an opinion
other than your own deserves to exist has caused me to dismiss you
as a viable discussion partner, right?
> Why don't you go back hacking perl4 code,
> instead of criticizing the design of a function that happens to show
> a flaw in your favourite toy.
>
> ) I have another suggestion for what sort could return in scalar context:
> )
> ) true if the array is already in sort, undef otherwise.
>
> Classic perl4 thinking: Let's overload it to do something related,
> but different!
Errr, having sort() return the number of elements is overloading
it to do something *not related* but different.
So you are saying that having sort do something unrelated to sorting
is preferable to having sort do something that *is* related to sorting?
Jim can make his own points, you don't really need to step
in like this to help him make his point!
heh.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Wed, 31 Aug 2011 05:53:25 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <86hb4xn3ne.fsf@red.stonehenge.com>
>>>>> "Rainer" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>> The deliberate choice was made because the language designer didn't see any
>> use cases. If there *is* a use case, then that (not seeing a use case) is
>> quite literally an oversight.
Rainer> If sort would return pi in scalar context, that would also be useful
Rainer> in some specific situations (as would any other value). But there is
Rainer> no more relation between the function of sort (return a specific
Rainer> permutation of its arguments) and 3.1415... than there is between
Rainer> permuting arguments and counting arguments.
I even addressed this point beginning in one of the early editions of
"Learning Perl", adding that being undefined, there was nothing
preventing sort in a scalar context from invoking "nethack". I do
recall a patch some number of years later (in jest) on P5P to do exactly
that. :)
The only serious proposals for scalar sort that I've seen are (a) a
boolean to say "yes, this list is already sorted", or perhaps (b) a
value between 0 and 1 as to "how sorted" the list already was, based on
a single pass of the sort comparator against adjacent elements. Not
sure when I would have used either one though.
if (sort { $a <=> $b } @list) { # this is already numerically sorted
...
}
print "Just another Perl hacker,"; # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
------------------------------
Date: Wed, 31 Aug 2011 14:00:26 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <slrnj5sfjq.1aec.willem@toad.stack.nl>
Tad McClellan wrote:
) Willem <willem@toad.stack.nl> wrote:
)> Jim Gibson wrote:
)
)> ) Any problems with maintenance of your code is more likely going to be
)> ) due to poor design.
)>
)> Why did you feel the need to throw in a gratuitous ad hominem attack ?
)
) It is neither gratuitous nor ad hominem.
)
) It is entirely possible, whether you agree with it or not,
) that it *is* a poor design.
That *what* is ?
Reread the statement. There is no 'it' being referred to.
) Offering an opinion (even if different) is not "gratuitous".
)
) He didn't say that _you_ were bad, he said that your _code_ was bad,
) so, not "ad hominem" either...
)
) A criticism of your code is not a criticism of you.
You snipped the part that this was a response to. It was not a piece of
code. It was a side remark about the merits of different workarounds in
regards to maintenance.
Hell, I didn't even post any real code, just some example snippets,
so there is no code to criticize.
So I stand by my opinion that it was a gratuitous ad hominem attack.
)> You do realise that this very comment caused me to dismiss you as a viable
)> discussion partner, right ?
)
) You do realise that being unable to acknowledge that an opinion
) other than your own deserves to exist has caused me to dismiss you
) as a viable discussion partner, right?
The 'opinion other than your own' was that I, apparently, use poor code
design. Which was based on nothing.
You are correct that it is an opinion. If I were to call you a jerk and an
asshole, that would be an opinion as well. The naked fact that something
is an opinion does not make it okay to spew it, nor does it negate the fact
that it is an attack.
)> ) I have another suggestion for what sort could return in scalar context:
)> )
)> ) true if the array is already in sort, undef otherwise.
)>
)> Classic perl4 thinking: Let's overload it to do something related,
)> but different!
)
) Errr, having sort() return the number of elements is overloading
) it to do something *not related* but different.
I have already explained why this is false.
Simply restating it is not going to make it any less false.
Having sort() return the number of elements is logical and consistent.
See the arguments I presented crossthread, none of which have been refuted
(only blatantly dismissed).
To hammer in the last nail: It works exactly that way in Perl6.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Wed, 31 Aug 2011 12:01:58 -0400
From: sreservoir <sreservoir@gmail.com>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <j3lltm$4sn$1@dont-email.me>
On 08/31/2011 07:44 AM, Rainer Weikusat wrote:
> pacman@kosh.dhis.org (Alan Curry) writes:
>> In article<slrnj5qbk5.pp7.willem@toad.stack.nl>,
>> Willem<willem@toad.stack.nl> wrote:
>>> Rainer Weikusat wrote:
>>> ) There is actually at least on similar operation in Perl, namely,
>>> ) reverse, which also returns a permutation of the input list. In scalar
>>> ) context, it will concatenate whatever the elements on the list
>>> ) stringify to and return a reversed string. This seems a little
>>> ) arbitrary and not really useful in many cases, eg,
>>> )
>>> ) [rw@tear]~ $perl -de 0
>>> )
>>> ) Loading DB routines from perl5db.pl version 1.3
>>> ) Editor support available.
>>> )
>>> ) Enter h or `h h' for help, or `man perldebug' for more help.
>>> )
>>> ) main::(-e:1): 0
>>> ) DB<1> print scalar(reverse(\$a, \$b, \$c))
>>> ) )0efcb38x0(RALACS)0ffcb38x0(RALACS)040db38x0(RALACS
>>>
>>> Wow that's pretty useless!
>>
>> But in the simplest case (a single string argument), the behavior of scalar
>> reverse is perfectly logical:
>>
>> $x = "foobar";
>> $y = reverse $x;
>> say $y;
>>
>> If a language built for text processing didn't have a reverse-string
>> operation, that would be weird.
>
> A 'reverse string' operation which also works in list context had
> nevertheless been a better idea, cf
>
> DB<16> p map { reverse $_; } qw(ab bc de)
> abbcde
% perl -E'say for map { ~~reverse $_; } qw(ab bc de)'
ba
cb
ed
when you want scalar context, just ask for it.
------------------------------
Date: Wed, 31 Aug 2011 12:09:35 -0400
From: sreservoir <sreservoir@gmail.com>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <j3lmbv$4sn$2@dont-email.me>
On 08/31/2011 10:00 AM, Willem wrote:
> [snip]
in short, you remain committed to your opinion, and it will not change.
------------------------------
Date: Wed, 31 Aug 2011 17:19:39 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <874o0xa6zo.fsf@sapphire.mobileactivedefense.com>
sreservoir <sreservoir@gmail.com> writes:
> On 08/31/2011 07:44 AM, Rainer Weikusat wrote:
>> pacman@kosh.dhis.org (Alan Curry) writes:
[...]
>>> But in the simplest case (a single string argument), the behavior of scalar
>>> reverse is perfectly logical:
>>>
>>> $x = "foobar";
>>> $y = reverse $x;
>>> say $y;
>>>
>>> If a language built for text processing didn't have a reverse-string
>>> operation, that would be weird.
>>
>> A 'reverse string' operation which also works in list context had
>> nevertheless been a better idea, cf
>>
>> DB<16> p map { reverse $_; } qw(ab bc de)
>> abbcde
>
> % perl -E'say for map { ~~reverse $_; } qw(ab bc de)'
> ba
> cb
> ed
>
> when you want scalar context, just ask for it.
I didn't ask. Does this perhaps tell something to you
------------------------------
Date: Wed, 31 Aug 2011 12:35:16 -0400
From: sreservoir <sreservoir@gmail.com>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <j3lns4$l5t$1@dont-email.me>
On 08/31/2011 12:19 PM, Rainer Weikusat wrote:
> sreservoir<sreservoir@gmail.com> writes:
>> On 08/31/2011 07:44 AM, Rainer Weikusat wrote:
>>> pacman@kosh.dhis.org (Alan Curry) writes:
>
> [...]
>
>>>> But in the simplest case (a single string argument), the behavior of scalar
>>>> reverse is perfectly logical:
>>>>
>>>> $x = "foobar";
>>>> $y = reverse $x;
>>>> say $y;
>>>>
>>>> If a language built for text processing didn't have a reverse-string
>>>> operation, that would be weird.
>>>
>>> A 'reverse string' operation which also works in list context had
>>> nevertheless been a better idea, cf
>>>
>>> DB<16> p map { reverse $_; } qw(ab bc de)
>>> abbcde
>>
>> % perl -E'say for map { ~~reverse $_; } qw(ab bc de)'
>> ba
>> cb
>> ed
>>
>> when you want scalar context, just ask for it.
>
> I didn't ask. Does this perhaps tell something to you
it could be easier if scalar and list reverse were different, sure,
but as it is, if it doesn't work properly in list context with only
one argument, then you add more unnecessary complication than if it
simply required you to ask for scalar context when you want it.
------------------------------
Date: Wed, 31 Aug 2011 18:02:33 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <slrnj5stpp.2h9a.willem@toad.stack.nl>
sreservoir wrote:
) On 08/31/2011 10:00 AM, Willem wrote:
)> [snip]
)
) in short, you remain committed to your opinion, and it will not change.
In the absence of convincing counter arguments, or even refutations of the
arguments I presented, why should I not remain convinced of my opinion ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Wed, 31 Aug 2011 12:18:49 -0700
From: sln@netherlands.com
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <sn1t57d4uf32im0cjq2f4ncc4kg200td5s@4ax.com>
On Tue, 30 Aug 2011 16:52:14 +0000 (UTC), Willem <willem@toad.stack.nl> wrote:
>sln@netherlands.com wrote:
>) I don't know why this is the case, but you should fix it up in the
>) function that wraps the return of sort().
>
>My apologies.
>I hadn't made clear that I was well aware how to work around this issue.
>
>
No apologies are necessary. Neither were your confusing examples.
A simple fyi: print 'undef' if !defined sort();
for those that don't already know. Anything more is meaningless.
-sln
------------------------------
Date: Wed, 31 Aug 2011 21:18:52 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <slrnj5t28s.1tt.hjp-usenet2@hrunkner.hjp.at>
On 2011-08-31 00:18, Jim Gibson <jimsgibson@gmail.com> wrote:
> I have another suggestion for what sort could return in scalar context:
>
> true if the array is already in sort, undef otherwise.
if (sort @foo) {
...
}
die "..." unless sort @bar;
Yes, makes sense.
hp
------------------------------
Date: Wed, 31 Aug 2011 20:35:38 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <87zkip8jcl.fsf@sapphire.mobileactivedefense.com>
Willem <willem@toad.stack.nl> writes:
> Rainer Weikusat wrote:
> ) I usually prefer the term 'subroutine' because it emphasizes that this
> ) is not a function in the mathematical sense:
>
> You should be worrying more about the definition of 'function' in the
> computer sciences, because that's much more closely related to
> programming.
People who plunder 'alien sciences' for terms should be worried about
the misunderstandings and -conceptions which result when other people
encounter a seemingly familiar term that actually refers to something
completely different. Eg, probably, the reason why people write C code like
this:
int larger_length(char const *s0, char const *s1)
{
if (strlen(s0) > strlen(s1)) return strlen(s0);
else if (strlen(s1) > strlen(s0) return strlen(s1);
return -1;
}
is that they lack the intuitive understanding of the difference
between what C calls 'a function' (a subroutine executing a particular
algorithm) and a mathematical function (which doesn't "do" anything
but defines a mapping from elements of one set to elements of a second
set).
But that was just supposed to demonstrate that use of the term
'subroutine' doesn't indicate anything about a relation to Perl4 (and
not even to Perl, although these things are called 'subroutines' in
the Perl documentation).
[...]
> )> The deliberate choice was made because the language designer didn't see any
> )> use cases. If there *is* a use case, then that (not seeing a use case) is
> )> quite literally an oversight.
> )
> ) If sort would return pi in scalar context, that would also be useful
> ) in some specific situations (as would any other value). But there is
> ) no more relation between the function of sort (return a specific
> ) permutation of its arguments) and 3.1415... than there is between
> ) permuting arguments and counting arguments.
>
> Yes there is. If you view sort in a functional-programming way, then
> it is: 'array -> sort -> array'. Using an array as a scalar gives
> the number of elements. Therefore using the result of sort as a scalar
> should give the number of elements as well. Simple logic.
Evaluating an array in a scalar context returns the number of
arguments in the array. Leaving the minor impreciseness aside, your
argument falls down at two levels:
1. The Perl sort isn't defined based on arrays but on lists and
evaluating a list in a scalar context returns the last member of the
list. Consequently, if sort was context-agnostic, it would return the
largest value on the input list, not the number of elements.
2. Since sort isn't context agnostic, it's behaviour in scalar
context is whatever someone considered sensible in this
situation. 'Counting elements' and 'permuting elements' are still two
completely different things. Consequently, there is no reason why a
function supposed to generate a permutation should suddenly return a
count in a different context. Especially considering that this count
is already known to the caller because it is the number of arguments
passed to the function.
> Compare, for example, a completely OO language, where there is a 'list'
> class. To get the perl behaviour of number-of-elements, you would simply
> implement a convert-to-integer member function, which the language then
> automatically calls whenever it has a 'list' but wants an 'integer'.
I certainly wouldn't do that but implement a 'count items on list'
subroutine instead.
> Now, there is a sort function which takes a 'list' object and returns a
> 'list' object. It is left as an exercise to figure out what would happen
> if you were to use sort() but want the result as an integer.
>
> PS: As far as I can tell from the online docs, it works like this
> in Perl6 as well.
Then, you should perhaps user Perl6 and not Perl5 ...
------------------------------
Date: Wed, 31 Aug 2011 20:37:41 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <87vctd8j96.fsf@sapphire.mobileactivedefense.com>
sreservoir <sreservoir@gmail.com> writes:
> On 08/31/2011 12:19 PM, Rainer Weikusat wrote:
>> sreservoir<sreservoir@gmail.com> writes:
>>> On 08/31/2011 07:44 AM, Rainer Weikusat wrote:
>>>> pacman@kosh.dhis.org (Alan Curry) writes:
>>
>> [...]
>>
>>>>> But in the simplest case (a single string argument), the behavior of scalar
>>>>> reverse is perfectly logical:
>>>>>
>>>>> $x = "foobar";
>>>>> $y = reverse $x;
>>>>> say $y;
>>>>>
>>>>> If a language built for text processing didn't have a reverse-string
>>>>> operation, that would be weird.
>>>>
>>>> A 'reverse string' operation which also works in list context had
>>>> nevertheless been a better idea, cf
>>>>
>>>> DB<16> p map { reverse $_; } qw(ab bc de)
>>>> abbcde
>>>
>>> % perl -E'say for map { ~~reverse $_; } qw(ab bc de)'
>>> ba
>>> cb
>>> ed
>>>
>>> when you want scalar context, just ask for it.
>>
>> I didn't ask. Does this perhaps tell something to you
>
> it could be easier if scalar and list reverse were different, sure,
> but as it is, if it doesn't work properly in list context with only
> one argument, then you add more unnecessary complication than if it
> simply required you to ask for scalar context when you want it.
I did not ask a question a la "Oh my god! I need to reverse the items
on this list and cannot figure out how !! PLEASE HEEELP MEEEEE !!!"
because I wasn't looking for the answer to this question.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3486
***************************************
