TITLE

Add list keyword to force list context (like scalar)

VERSION

  Maintainer: Nathan Wiger <nate@wiger.org>
  Date: 29 Aug 2000
  Last Modified: 11 Sep 2000
  Mailing List: perl6-language@perl.org
  Number: 175
  Version: 2
  Status: Retracted

ABSTRACT

Currently, we have a scalar keyword to force scalar context. However, we have no corresponding 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, 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 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.

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

DESCRIPTION

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 list context keyword makes things clearer and easier to understand in some situations, just like 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, list can be used to force list context, just like 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 scalar.

There are several arguments against 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.

Arguments Against

We don't need `list`, it's unnecessary

So is scalar. There are ways around using scalar, just as there are ways around using list. While they are not exactly analogous workarounds, there is still no real reason scalar is needed and 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 sin. However, we support them to make easy things easier. The same philosophy should apply here.

What next, `hash`, `boolean`, and other keywords?

No. Every Perl data type is built on either a list (arrays and hashes) or a scalar (scalars) context. Other contexts are not analogous or even closely related.

Forcing `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 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 list keyword.

The keyword `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.

IMPLEMENTATION

Hold on.

MIGRATION

None. This adds new functionality.

REFERENCES

Camel-3, p. 778 (The section on 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).