[32220] in Perl-Users-Digest
Perl-Users Digest, Issue: 3485 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Aug 31 06:10:08 2011
Date: Wed, 31 Aug 2011 03:09:06 -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: 3485
Today's topics:
Italian Perl Workshop - 7, 8 and 9 september 2011 <nospan-nonsolosoft@diff.org>
Re: My code works but is clunky and inelegant; help to <rweikusat@mssgmbh.com>
Re: My code works but is clunky and inelegant; help to <hjp-usenet2@hjp.at>
Re: My code works but is clunky and inelegant; help to <rweikusat@mssgmbh.com>
Re: Why does sort return undef in scalar context ? <rweikusat@mssgmbh.com>
Re: Why does sort return undef in scalar context ? <kst-u@mib.org>
Re: Why does sort return undef in scalar context ? <willem@toad.stack.nl>
Re: Why does sort return undef in scalar context ? <willem@toad.stack.nl>
Re: Why does sort return undef in scalar context ? <NoSpamPleaseButThisIsValid3@gmx.net>
Re: Why does sort return undef in scalar context ? <willem@toad.stack.nl>
Re: Why does sort return undef in scalar context ? <rweikusat@mssgmbh.com>
Re: Why does sort return undef in scalar context ? <willem@toad.stack.nl>
Re: Why does sort return undef in scalar context ? (Randal L. Schwartz)
Re: Why does sort return undef in scalar context ? <brian.d.foy@gmail.com>
Re: Why does sort return undef in scalar context ? <willem@toad.stack.nl>
Re: Why does sort return undef in scalar context ? (Alan Curry)
Re: Why does sort return undef in scalar context ? <jimsgibson@gmail.com>
Re: Why does sort return undef in scalar context ? <willem@toad.stack.nl>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 31 Aug 2011 11:08:57 +0200
From: Ferruccio Zamuner <nospan-nonsolosoft@diff.org>
Subject: Italian Perl Workshop - 7, 8 and 9 september 2011
Message-Id: <j3ktp7$iqd$1@nnrp.ngi.it>
Hello,
The Italian Perl Workshop will happen on 8-9 September 2011. The 2-days
event usually has about 120 attendees and talks both in English and
Italian language, so it's suitable for Italians and for foreigners.
Attendance is free of charge.
This year we're moving away from the usual location in Pisa. The
conference will be held in Torino (Turin).
We already have a couple of confirmed guests:
Matt Trout (mst) - Catalyst, DBIx::Class, Devel::Declare, ... developer
Alexis Sukrieh - Dancer developer
We'll also have Ingy döt Net, author of Kwiki and of modules such as
Inline, pQuery, Module::Package and YAML, attend the workshop. He's
going to give a couple of talks, too.
Other !Perl arguments in this issue are:
* PostgreSQL 9.1 (with live streaming replication and new features of
last release)
* Dojo 1.7 (javascript framework that rocks)
* Arduino (yes, it's hardware, but Open Source).
* Haskell and more.
The full schedule schedule is available here:
http://conferences.yapceurope.org/ipw2011/schedule?day=2011-09-08
http://www.nonsolosoft.com/perl_2011/IPW_fly_image.png
Mole Antonelliana, Egyptian Museum, Sacra Sindone: these are only some
of the things which are waiting for you in Turin. The city also features
a vast choice of restaurant and bars, with a night life which is among
the most thriving in Italy. The city, because of its international
airport, is easily and relatively cheap to reach, both with mainstream
and low cost carriers. High speed trains also connect it to France,
Switzerland and the rest of Europe. IPW is great change to visit Turin!
For more information and to subscribe, please visit the workshop web
site at:
http://www.perl.it/workshop/
See you in Turin!
------------------------------
Date: Tue, 30 Aug 2011 13:06:03 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: My code works but is clunky and inelegant; help to improve it?
Message-Id: <87ty8zp0ic.fsf@sapphire.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
[...]
>> When undef is used as a string, it acts like the empty string.
>
> Only if "use warnings 'uninitialized'" is not in effect.
> Otherwise it emits a warning.
A scalar value is interpreted as TRUE in the Boolean sense if
it is not the null string or the number 0 (or its string
equivalent, "0"). The Boolean context is just a special kind
of scalar context where no conversion to a string or a number
is ever performed.
There are actually two varieties of null strings (sometimes
referred to as "empty" strings), a defined one and an undefined
one.
[perldata(1)]
------------------------------
Date: Tue, 30 Aug 2011 18:52:17 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: My code works but is clunky and inelegant; help to improve it?
Message-Id: <slrnj5q5a1.trk.hjp-usenet2@hrunkner.hjp.at>
On 2011-08-30 12:06, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>>> When undef is used as a string, it acts like the empty string.
>>
>> Only if "use warnings 'uninitialized'" is not in effect.
>> Otherwise it emits a warning.
>
> A scalar value is interpreted as TRUE in the Boolean sense if
> it is not the null string or the number 0 (or its string
> equivalent, "0"). The Boolean context is just a special kind
> of scalar context where no conversion to a string or a number
> is ever performed.
This is true but a complete non-sequitur. Tad was explicitely talking
about undef being used in a string context, not a boolean context.
> There are actually two varieties of null strings (sometimes
> referred to as "empty" strings), a defined one and an undefined
> one.
Except that undef is not a string. A scalar may have several types (even
at the same time): String, integer floating-point, reference, ... But
undef is none of them.
hp
------------------------------
Date: Tue, 30 Aug 2011 18:11:21 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: My code works but is clunky and inelegant; help to improve it?
Message-Id: <87hb4yq0xy.fsf@sapphire.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
> On 2011-08-30 12:06, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>>>> When undef is used as a string, it acts like the empty string.
>>>
>>> Only if "use warnings 'uninitialized'" is not in effect.
>>> Otherwise it emits a warning.
>>
>> A scalar value is interpreted as TRUE in the Boolean sense if
>> it is not the null string or the number 0 (or its string
>> equivalent, "0"). The Boolean context is just a special kind
>> of scalar context where no conversion to a string or a number
>> is ever performed.
>
> This is true but a complete non-sequitur. Tad was explicitely talking
> about undef being used in a string context, not a boolean context.
This is the context for the second paragraph, so that a reader can
easier find that in the document I was quoting.
>> There are actually two varieties of null strings (sometimes
>> referred to as "empty" strings), a defined one and an undefined
>> one.
>
> Except that undef is not a string.
This was a quote from the Perl documentation (strangely, the reference
to the source got deleted somehow ...) and this means it is pretty
pointless that you try to argue against it. Submit a patch which
rewrites the document such that it reflects the viewpoint you consider
to be more proper and then, you can confidently state that "since
version X.Y, the Perl documentation tries to hide the fact that undef
stringifies to an empty string for greater political correctness[*]"
([*] insert whatever other 'philosophical reason' you happen to like
here).
Until this has happened, 'undefined null strings' do exist in Perl.
------------------------------
Date: Tue, 30 Aug 2011 13:24:11 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <87pqjnozo4.fsf@sapphire.mobileactivedefense.com>
Willem <willem@toad.stack.nl> writes:
[...]
> for my $s (get_sorted_things($foo)) {
> do_something_with($s);
> }
> ...
> if (get_sorted_things($bar)) {
> warn "There were things for $bar!\n";
> }
> ...
> sub get_sorted_things
> {
> my %unique = map { $_->Key => $_ } get_things();
> return sort { $a->Property cmp $b->Property } values %unique;
> }
>
> And, because somebody decided that sort should always return undef
> when called in scalar context, this does not work!
The sort documentation actually says
sort SUBNAME LIST
sort BLOCK LIST
sort LIST
In list context, this sorts the LIST and returns the
sorted list value. In scalar context, the behaviour of
"sort()" is undefined.
> Why was it decided that sort returns undef in scalar context ?
> IMO it is much more logical and consistent to have it return the
> number of objects in the list that is to be sorted
'Much more logical' seems like a matter of opinion here. But it is
certainly not 'more consistent since evaluating a list in scalar
context returns the final element "as with the C comma operator"
(perldata(1)). Evaluating an array in scalar context yields the number
of elements in the array. The keys function behaves in this way but
expecting that to return the number of keys in a scalar context makes
IMHO more sense than expecting sort to return the number of items to
be sorted in a scalar context.
------------------------------
Date: Tue, 30 Aug 2011 08:49:01 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <ln62levr0y.fsf@nuthaus.mib.org>
Willem <willem@toad.stack.nl> writes:
> Today I got bitten by a very strange bug/feature:
>
> I wrote a function that returned a sorted list of things.
> This function was used in several places, sometimes to use the things in
> some way, and in one place just to check if it returned any things.
>
> For example:
>
> ...
> for my $s (get_sorted_things($foo)) {
> do_something_with($s);
> }
> ...
> if (get_sorted_things($bar)) {
> warn "There were things for $bar!\n";
> }
> ...
> sub get_sorted_things
> {
> my %unique = map { $_->Key => $_ } get_things();
> return sort { $a->Property cmp $b->Property } values %unique;
> }
>
> And, because somebody decided that sort should always return undef
> when called in scalar context, this does not work!
>
> Why was it decided that sort returns undef in scalar context ?
> IMO it is much more logical and consistent to have it return the
> number of objects in the list that is to be sorted (it doesn't even
> need to sort them for that).
Any "sensible" behavior for sort() in scalar context would not (need to)
sort anything -- which implies to me that calling sort() in such a
context doesn't make much sense. Similarly, "get_sorted_things($bar)"
would be better written as some other operation on $bar that doesn't
imply an unnecessary expensive sort.
As Rainer Weikusat points out, the behavior of sort() in scalar context
is actually undefined. IMHO it would make more sense for it to be an
error.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Tue, 30 Aug 2011 16:51:20 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <slrnj5q588.2tjr.willem@toad.stack.nl>
Tad McClellan wrote:
) Willem <willem@toad.stack.nl> wrote:
)> Today I got bitten by a very strange bug/feature:
)>
)> I wrote a function that returned a sorted list of things.
<snip>
)> sub get_sorted_things
)> {
)> my %unique = map { $_->Key => $_ } get_things();
)> return sort { $a->Property cmp $b->Property } values %unique;
)> }
)
) ... but get_sorted_things() does not consult any arguments!
)
) What is the relationship between $foo and $bar and get_things()?
It was JUST AN EXAMPLE! I happened to forget to include the argument.
Here, I'll fix it for you:
sub get_sorted_things
{
my ($arg) = @_;
my %unique = map { $_->Key => $_ } get_things($arg);
return sort { $a->Property cmp $b->Property } values %unique;
}
Better ? Or are you going to harp about that you don't know what
get_things does ? It's irrelevant to the point of the example.
) Before I got to the definition of get_sorted_things(),
) I had guessed that $bar was an arrayref of things to sort,
) if it was then you could just do:
)
) if (@$bar) {
) warn "There were things for $bar!\n";
)
) But it isn't. So you can't.
)
) And since I don't know what $bar is, I cannot even attempt to
) help you here.
I don't need help. The code is just to exemplify what I ran into.
I came up with a workaround as soon as I figured out the bug in sort().
The arguments are irrelevant; all they do is show that the function
returns a different sorted list on different invocations.
What I want to know is *why* Larry chose to have sort() return undef
in scalar context.
)> And, because somebody
)
) Larry Wall.
)
)> decided that sort should always return undef
)> when called in scalar context, this does not work!
)
) So fix it!
)
) sub get_sorted_things {
) die "get_sorted_things() was called with a useless argument\n" if @_;
)
) my %unique = map { $_->Key => $_ } get_things();
) if (wantarry) {
) return sort { $a->Property cmp $b->Property } values %unique;
) }
) else {
) return keys %unique;
) }
) }
I am very well aware that (and how) you can workaround that bug, TYVM.
)> Why was it decided that sort returns undef in scalar context ?
)
) I dunno.
)
) Have to ask Larry, or search for comments in the perl code I guess.
)
) I would want it to return the first element, or the last element,
) or the median element, or ... but all of those would O(n log n),
) (ie. expensive, there are algorithms for determinig those things that
) have a better running time) so then I'd give up and make it
) undefined in a scalar context.
)
) I don't know if that was his thinking or not.
Well, if you use an array in scalar context, you get the count of items.
If you use sort on an array, you get an array. Therefore, if you use sort
on an array in scalar context, you should get the count of the array.
I am well aware that you actually get a list, and that a list in scalar
context does something different than an array in scalar context. That
alone is quite horrid, IMO.
)> IMO it is much more logical and consistent to have it return the
)> number of objects in the list that is to be sorted
)
) If you are writing a call to sort(), then you already know the list
) of things that you are going to ask sort() to sort.
Not always, which is why I provided the example above.
) Why run it through another function only to find out something
) that you already have access to?
Reusability.
Here's the same example, but abstractly:
- I have a function that does some work to retrieve a list of items, and as
the final step it sorts the items.
- Most of the time, I want to use the sorted list (in order), but sometimes
I just want to check if there were any items.
Now, because sort() returns undef, I have to make two separate functions,
one which returns the list, and another that returns the sorted list.
(The second uses the first of course).
I consider that a workaround.
) Why would we want to call a function named sort() if we wanted
) something that did not even require sorting?
Reusability. Polymorphism. Consistency. See above.
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: Tue, 30 Aug 2011 16:52:14 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <slrnj5q59u.2tjr.willem@toad.stack.nl>
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.
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: Tue, 30 Aug 2011 19:10:49 +0200
From: Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <4e5d1999$0$6635$9b4e6d93@newsspool2.arcor-online.net>
Am 30.08.2011 18:51, schrieb Willem:
> Now, because sort() returns undef, I have to make two separate functions,
> one which returns the list, and another that returns the sorted list.
> (The second uses the first of course).
Well, you could force list context.
$ perl -E'sub x{return sort qw(1 4 2)}; $n=()=x(); say $n'
3
- Wolf
------------------------------
Date: Tue, 30 Aug 2011 17:14:39 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <slrnj5q6jv.2tjr.willem@toad.stack.nl>
Rainer Weikusat wrote:
) The sort documentation actually says
)
) sort SUBNAME LIST
) sort BLOCK LIST
) sort LIST
)
) In list context, this sorts the LIST and returns the
) sorted list value. In scalar context, the behaviour of
) "sort()" is undefined.
Ah, I must have found some different documentation.
)> Why was it decided that sort returns undef in scalar context ?
)> IMO it is much more logical and consistent to have it return the
)> number of objects in the list that is to be sorted
)
) 'Much more logical' seems like a matter of opinion here. But it is
) certainly not 'more consistent since evaluating a list in scalar
) context returns the final element "as with the C comma operator"
The same could be said for map and grep. But those do return the count.
) (perldata(1)). Evaluating an array in scalar context yields the number
) of elements in the array. The keys function behaves in this way but
) expecting that to return the number of keys in a scalar context makes
) IMHO more sense than expecting sort to return the number of items to
) be sorted in a scalar context.
IMO it's irrelevant that it makes "more" sense.
I'm just countering the argument that it "doesn't make sense"
by providing an example where it does make sense.
If you were to say "It doesn't make enough sense to warrant implementing
it that way", then *that* would be a matter of 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: Tue, 30 Aug 2011 19:26:14 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <87d3fmpxh5.fsf@sapphire.mobileactivedefense.com>
Willem <willem@toad.stack.nl> writes:
> Rainer Weikusat wrote:
[...]
> )> Why was it decided that sort returns undef in scalar context ?
> )> IMO it is much more logical and consistent to have it return the
> )> number of objects in the list that is to be sorted
> )
> ) 'Much more logical' seems like a matter of opinion here. But it is
> ) certainly not 'more consistent since evaluating a list in scalar
> ) context returns the final element "as with the C comma operator"
>
> The same could be said for map and grep. But those do return the count.
>
> ) (perldata(1)). Evaluating an array in scalar context yields the number
> ) of elements in the array. The keys function behaves in this way but
> ) expecting that to return the number of keys in a scalar context makes
> ) IMHO more sense than expecting sort to return the number of items to
> ) be sorted in a scalar context.
>
> IMO it's irrelevant that it makes "more" sense.
> I'm just countering the argument that it "doesn't make sense"
> by providing an example where it does make sense.
The purpose of map and grep is to produce an output list based on some
input list and 'an operation' which is sucessively performed on each
element of the input list. In both cases, the number of elements on
the output list can be different from the number of elements on the
input list, trivially for grep because its purpose is to filter the
input list based on the return value of the operation and somewhat
less trivially for map because 'the operation' may return an arbitrary
number of output elements for each input element. In contrast to this,
the purpose of sort is to return a permutation of the elements on the
input list which implies that the number doesn't change. Consequently,
it is pointless to invoke sort to determine this number.
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
and extending this to sort, while 'consistent' also doesn't exactly
appear useful:
DB<2> print join('', sort(split(//, join('', \$a, \$b, \$c))))
((()))00000003334888AAAAAACCCLLLRRRSSSbbbccdefffxxx
------------------------------
Date: Tue, 30 Aug 2011 18:40:05 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <slrnj5qbk5.pp7.willem@toad.stack.nl>
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!
You know, I think this stems from the old days when Perl was more of
a simple scripting language, hacked together with functionality added
when it "seemed useful", instead of making it consistent or anything.
So I guess I have my answer.
I wonder, what does Perl6 do with the result of sorting an array,
when it is evaluated for its truth value?
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: Tue, 30 Aug 2011 11:36:39 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <86r542oifc.fsf@red.stonehenge.com>
>>>>> "Willem" == Willem <willem@toad.stack.nl> writes:
Willem> ) 'Much more logical' seems like a matter of opinion here. But it is
Willem> ) certainly not 'more consistent since evaluating a list in scalar
Willem> ) context returns the final element "as with the C comma operator"
Willem> The same could be said for map and grep. But those do return
Willem> the count.
They return the count because the count is variable and can't be
determined by a trivial inspection of the input.
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: Tue, 30 Aug 2011 15:46:23 -0500
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <300820111546238493%brian.d.foy@gmail.com>
In article <slrnj5nu2a.811.willem@toad.stack.nl>, Willem
<willem@toad.stack.nl> wrote:
> Why was it decided that sort returns undef in scalar context ?
> IMO it is much more logical and consistent to have it return the
> number of objects in the list that is to be sorted (it doesn't even
> need to sort them for that).
If that's what you wanted, you wouldn't use sort() at all, so the
language doesn't think to implement that context for an operator who's
job is to sort.
It's like asking why print() doesn't do your taxes.
------------------------------
Date: Tue, 30 Aug 2011 20:59:07 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <slrnj5qjor.1i6p.willem@toad.stack.nl>
brian d foy wrote:
) In article <slrnj5nu2a.811.willem@toad.stack.nl>, Willem
)<willem@toad.stack.nl> wrote:
)
)> Why was it decided that sort returns undef in scalar context ?
)> IMO it is much more logical and consistent to have it return the
)> number of objects in the list that is to be sorted (it doesn't even
)> need to sort them for that).
)
) If that's what you wanted, you wouldn't use sort() at all, so the
) language doesn't think to implement that context for an operator who's
) job is to sort.
I explained in the rest of the post why, in fact, one would in some cases,
so the language should have thought to implement it. It's not like it's
doing anything useful in scalar context at the moment. Hell, it's
even undefined behaviour (as I found out crossthread).
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.
(There are other options, such as first assigning to an array and then
returning the array, but the next maintenance programmer to come around
might think 'hey I can return that sorted list directly!' and break
stuff again.)
NB: I do not need help working around this issue. This thread is
a theoretical discussion on the merits of sort in scalar context.
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: Tue, 30 Aug 2011 23:08:43 +0000 (UTC)
From: pacman@kosh.dhis.org (Alan Curry)
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <j3jqhr$2jp$1@speranza.aioe.org>
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.
--
Alan Curry
------------------------------
Date: Tue, 30 Aug 2011 17:18:20 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <300820111718208640%jimsgibson@gmail.com>
In article <slrnj5qjor.1i6p.willem@toad.stack.nl>, Willem
<willem@toad.stack.nl> wrote:
> brian d foy wrote:
> ) In article <slrnj5nu2a.811.willem@toad.stack.nl>, Willem
> )<willem@toad.stack.nl> wrote:
> )
> )> Why was it decided that sort returns undef in scalar context ?
> )> IMO it is much more logical and consistent to have it return the
> )> number of objects in the list that is to be sorted (it doesn't even
> )> need to sort them for that).
> )
> ) If that's what you wanted, you wouldn't use sort() at all, so the
> ) language doesn't think to implement that context for an operator who's
> ) job is to sort.
>
> I explained in the rest of the post why, in fact, one would in some cases,
> so the language should have thought to implement it. It's not like it's
> doing anything useful in scalar context at the moment. Hell, it's
> even undefined behaviour (as I found out crossthread).
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.
> 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.
>
> (There are other options, such as first assigning to an array and then
> returning the array, but the next maintenance programmer to come around
> might think 'hey I can return that sorted list directly!' and break
> stuff again.)
Any problems with maintenance of your code is more likely going to be
due to poor design.
I have another suggestion for what sort could return in scalar context:
true if the array is already in sort, undef otherwise.
--
Jim Gibson
------------------------------
Date: Wed, 31 Aug 2011 07:36:08 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <slrnj5rp38.24gc.willem@toad.stack.nl>
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. And the fact that you claim
that the *function* I wrote, with the given contract just below, is not
good design, but *without* giving any explanation for that claim, means
you're just trying to defend your narrow-minded view instead of actually
trying to think about it.
)> 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.
)> (There are other options, such as first assigning to an array and then
)> returning the array, but the next maintenance programmer to come around
)> might think 'hey I can return that sorted list directly!' and break
)> stuff again.)
)
) 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 ?
You do realise that this very comment 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!
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: 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 3485
***************************************
