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 Last-Modified: 11 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 175 Version: 2 Status: Retracted =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 NOTES ON RETRACTION On the surface makes sense. But in reality...Bad Idea. http://www.mail-archive.com/perl6-language%40perl.org/msg03404.html http://www.mail-archive.com/perl6-language%40perl.org/msg03489.html =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).
