develooper Front page | perl.perl5.porters | Postings from July 2009

Re: [PATCH] Remove implicit split to @_

Thread Previous | Thread Next
From:
Yitzchak Scott-Thoennes
Date:
July 9, 2009 21:45
Subject:
Re: [PATCH] Remove implicit split to @_
Message ID:
53849.97.113.117.246.1247201102.squirrel@webmail.efn.org
On Thu, July 9, 2009 8:49 pm, Michael G Schwern wrote:
> Yitzchak Scott-Thoennes wrote:
>> $field_count = () = split ...;
>
> Which doesn't work.
>
> $ perl -wle '$count = () = split / /, "foo bar baz";  print $count'
> 1

I assume you know the mistake you made there?  If not, consult the
split doc.

> Again, this underscores the point that there really needs to be a not
> clever way to do this.

I don't consider that clever.  It's the normal, unclever, way to
count an arbitrary list.

> I'd like to point out that this already works:
>
> my $count = split ...;

That's really the most important point.  It took me a while, but
consider my objections withdrawn, for whatever that's worth.

>> I'm not completely satisfied that "fixing" scalar context is the right
>> thing to do; just like with sort, where there are several "right" scalar
>>  context behaviors.
>
> sort() is a different story.  It always (and I'm sure someone can do some
>  trick to make this not true) returns the same number of elements as you
> put in.  So using it in scalar context is a no-op.  Thus making sort in
> scalar context do something else, like the first element, has some merit.
>
> split() returns a variable number of elements, so its at least
> interesting to get the count.
>
> I'd like to point out that we still don't have a working sort in scalar
> context.  We all agree that the current behavior is wrong but never agreed
> on what it should be.  I'd like this not to wind up the same way.

I think the existing behavior of sort is perfect, alerting you
to a mistake if you assume it works any other way.

>> With my C hat on, I'd expect it to return the first field, like strtok.
>>  Without it, I'd be as inclined to expect the last field as to expect
>> a count.
>
> While that might all be interesting, and we can come up with interesting
> things all day, like maybe it should return an array reference, it
> violates the general Perl rule of "arrays return the count in scalar
> context" (yes, I know perlfunc denies the existence of that rule) that
> similar core Perl functions follow.  Arrays, map and grep for example.
>
> In short, core Perl functions don't work that way.

A) we're not talking about an array, and B) core Perl functions work
in a great variety of ways, and I don't see any compelling justification
for your proposal...other than that that's how it already works, albeit
with dreadful side effects.

> We have decent ways to do this already:

We have decent ways to do everything, yes.  But that's an argument for
having it croak so no one ever wrongly guesses what it does without
then learning of their mistake.

> I'd like to point out this still leaves us open to what things like split
> and map and grep and sort should do in scalar context, return a lazily
> evaluated iterator.
> [...]
> But please don't let that hold up this simple patch.

OK by me.



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About