This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add C<list> keyword to force list context (like C<scalar>)
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 175
Status: Developing
=head1 ABSTRACT
Currently, we have a C<scalar> keyword to force scalar context. However,
we have no corresponding C<list> keyword, leading to constructs like
this:
foo( () = bar() ); # force list context
Which are clumsy, at best. Do they work? Yes. Is it easily readable and
maintainable code? Not really.
This RFC proposes a new keyword, C<list>, which forces list context.
This means the above can simply be written as:
foo(list bar()); # force list context
Which is consistent with similar uses of C<scalar>, and also makes the
code much more readable. This RFC does NOT propose any other keywords
because they are unnecessary. All data types in Perl are built on lists
and scalars.
=head1 DESCRIPTION
=head2 The Proposal
The purpose of this RFC is to increase clarity, make easy things easier,
and make Perl contexts more accessible. It is not to supplant the
current implicit typing methods, which are a beautiful thing.
The new C<list> context keyword makes things clearer and easier to
understand in some situations, just like C<scalar>:
foo(list bar()); # easy
foo( () = bar() ); # not as easy
foo(bar()); # easy
foo(scalar bar()); # not as easy
$count = list split /!/; # easy
$count = () = split /!/; # not as easy
my($arg1) = func; # easy
my $arg1 = list func; # not as easy
my $num = @a; # easy
my($num) = scalar @a; # not as easy
my($nextvar) = scalar <STDIN>; # Camel-3 p. 778, for clarity
my $nextvar = <STDIN>; # implicit
Here, C<list> can be used to force list context, just like C<scalar> can
be used to force scalar context. And, as the Camel-3 example shows, it
can be used for greater clarity if you so desire just like C<scalar>.
There are several arguments against C<list>, so I'll spend the remainder
of the RFC addressing them. There has already been a huge discussion on
this as well; please see the REFERENCES for links to the thread.
=head2 Arguments Against
=head3 We don't need C<list>, it's unnecessary
So is C<scalar>. There are ways around using C<scalar>, just as there
are ways around using C<list>. While they are not exactly analogous
workarounds, there is still no real reason C<scalar> is needed and
C<list> is not. Consider:
$num = scalar @a; # scalar explicit
$num = @a; # scalar implicit
$num = list @a; # list explicit
($num) = @a; # list implicit
We don't need 6 trigonometric functions, either - everything can be
derived from C<sin>. However, we support them to make easy things
easier. The same philosophy should apply here.
=head3 What next, C<hash>, C<boolean>, and other keywords?
No. Every Perl data type is built on either a C<list> (arrays and
hashes) or a C<scalar> (scalars) context. Other contexts are not
analogous or even closely related.
=head3 Forcing C<list> context is not a common problem
If it weren't, then it wouldn't have spawned a huge discussion already.
Also, Perl books would not have to make special notes of how to
artificially enforce C<list> context with special constructs:
() = funkshun();
$x = ( () = funk() );
Which could be easily rewritten as:
list funkshun;
$x = (list funk); # with one keyword, or...
$x = scalar list funk; # can chain to make explicit
Thanks to the new C<list> keyword.
=head3 The keyword C<list> adds nothing new
Except clarity, simplicity, and consistency, without having to sacrifice
any part of the existing language. If you don't like it, don't use it.
=head1 IMPLEMENTATION
Hold on.
=head1 MIGRATION
None. This adds new functionality.
=head1 REFERENCES
Camel-3, p. 778 (The section on C<scalar>)
Thanks to Bart Lateur for his input
There was an extensive, heated discussion between Tom C and myself on
this topic. I will post a link to the email archive as a follow-up after
this posts (it is not currently available on mail-archive.com).
