This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 17 August 2000
Last Modified: 14 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 128
Version: 3
Status: Developing
=head1 ABSTRACT
This RFC proposes that subroutine argument context specifiers be
extended in several ways, including allowing parameters to be typed and
named, and that a syntax be provided for binding arguments to named
parameters.
=head1 CHANGES
Added section describing named parameter interaction with named higher-order
function placeholders.
=head1 DESCRIPTION
It is proposed that the existing subroutine "prototype" mechanism
be replaced by optional formal parameter lists that allow parameters
to be named and their contexts specified.
The syntax for this would be:
sub subname ( type context(s) parameter_name : parameter_attributes ,
type context(s) parameter_name : parameter_attributes ,
type context(s) parameter_name : parameter_attributes ;
# end of required parameters
type context(s) parameter_name : parameter_attributes ,
# etc.
) : subroutine_attributes
{ body }
Each of the four components of a parameter specification -- type,
context, name, and attributes -- would be optional.
=head2 Contexts
The context specifiers would be:
$ parameter is scalar
@ parameter is array (eats remaining args)
% parameter is hash (eats remaining args)
/ parameter is qr'd string
parameter is subroutine reference or block
* parameter is typeglob (assuming they still exist)
"" parameter is bareword or character string
() parameter is an explicitly parenthesized list
Note that any of these specifiers may appear in any position in a
parameter list (especially C, which would no longer be constrained to
the first position).
The following prefix context modifier would be available:
\ parameter must be a reference,
argument is magically en-referenced if necessary
The following context attributes would be available:
:lazy argument is lazily evaluated
:uncurried( only) terminate curry propagation on argument
:noautovivthat is a (possibly nested) hash element or array
element is not autovivified.
:repeat{m,n} argument is variadic within the specified range
The following subsections describe each of these in detail.
The following grouping operator would also be available:
(...) specifies that the argument(s) are to be
treated collectively (i.e. by modifiers and attributes)
=head3 Automagically en-referenced arguments
The C\ modifier causes the modified parameter to automagically
convert its corresponding argument to a reference without list flattening.
The most common usage is in passing hashes and arrays as a single argument.
Note that the semantics of C\ attribute would be altered
slightly from those of Perl 5, so that a reference is Ialways passed for
that parameter. It would, of course, retain its magical
en-referencing coercion:
\$ argument must be scalar ref or start with $
scalar var magically en-referenced
\@ argument must be array ref or start with @,
array var magically en-referenced
\% argument must be hash ref of start with %,
hash var magically en-referenced
\/ argument must be qr'd string or /.../ or m/.../
/.../ or m/.../ magically qr'd to en-reference
\ arg must be sub reference, curried function, or block
block converted to anonymous sub ref
\* argument must be typeglob ref of start with *,
typeglob magically en-referenced
\""argument must be a string reference or a bareword,
bareword magically stringified and en-referenced
\()argument must be a parenthesized list or an anonymous
list constructor
parenthesized list is magically en-referenced
=head3 Lazy evaluation
If the Clazy attribute is used for a particular parameter, that parameter
is lazily evaluated. This means that it is only evaluated when the
corresponding named parameter (see below) -- or the corresponding element
of @_ -- is first accessed in some way, after which the evaluated value
is stored in the element in the usual way. Passing the parameter to another
subroutine or returning it as an lvalue does not count as an access.
Evaluating it in an Ceval
