Re: RFC 356 (v2) Dominant Value Expressions
With respect to: >=head1 TITLE >_Dominant Value Expressions >=head1 VERSION > >_Maintainer: Glenn Linderman <[EMAIL PROTECTED]> > >=head1 ABSTRACT > >An aid to determining if an input value has an impact on the result >of an expression whole program. Can also be used for Perl poetry. > >=head1 CHANGES My "vomment" - There are easy enough ways to accomplish your apparent desires that do not require more changes to this already tortured language. Please use them. This is just the sort of madness that one expects to appear in Perl6. What's next? RFC 3xx: Lazily evaluated domination ...Or perhaps RFC 3xx: Curried domination Apologies for the acid - but this is easier than a rippin' by ANtchrist. keisuke [EMAIL PROTECTED] heretics of Perl -- -- Get your firstname@lastname email for FREE at http://NamePlanet.com/?su
Re: [PATCH] multiple heredoc beginning in the same line
it's not so difficult, really. you just gotta know the trick: - cd into the repository you want, then run "git am". - Use your mail client's "view source" function (ctrl-u in thunderbird for example). - copy the complete mail source including headers - paste it into the terminal that's running git am - hit return if necessary, and ctrl-d done. I pushed the patch to our repository. Thanks for your work, francois! - Timo
RFC 6 (v2) Lexical variables made default
=head1 TITLE
Lexical variables made default
=head1 VERSION
Maintainer: J. David Blackstone <[EMAIL PROTECTED]>
Date: 1 August 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 6
=head1 ABSTRACT
Prior to version 5, all implementations of Perl were designed with
only dynamic (global) variables in mind. Perl5 provided lexical
variables in a backward compatible way, along with a pragma to force
either declaration of variables or import of dynamic variables. Perl6
should make lexical variables and required variable declarations the default.
=head1 DESCRIPTION
Dynamically-scoped variables can have many effects which are
counterintuitive and undesirable. In Perl5, lexically-scoped
variables are available with the C operator. Without C, a
variable is assumed to be dynamic.
Perl5 provides the C pragma, which forces the programmer to do
one of three things: 1) declare a variable to be lexical with C;
2) declare a variable to be dynamic with C; 3) import a dynamic
variable from another namespace with C or otherwise. This
forced declaration of variables is generally desirable as good
programming practice, although the ability does exist to turn off the
pragma when necessary.
There are very few circumstances in which dynamic variables have a
distinct advantage over lexicals. Most modules in the standard
library are deliberately written with C to avoid
interfering with other modules or the application programmer's code.
More recent and enlightened documentation and educational material
teaches the use of lexical variables as preferred.
In Perl6, the concept of C should on by default. Every
variable should be declared either as lexical with C or dynamic
with C. New Perl6 programmers should be immediately introduced
to lexical scoping and its benefits. The ability to disable the
strictness should be retained through C or an
equivalent, for "quick-and-dirty" programs, backward compatibility,
and where otherwise necessary or desired by those who Know What They
Are Doing.
This RFC is not suggesting that any of the other features of the
C pragma be on by default (such as C<'refs'> or C<'subs'>).
If that is desired, it should be submitted in a separate RFC.
The C operator is misnamed, since it operates on dynamic
(global) variables. This operator should be removed or renamed, but
this should be the subject of a separate RFC.
=head1 IMPLEMENTATION
I don't know enough about internals to say anything about
implementation from that standpoint.
The following program examples show how declarations would work.
my $name = "J. David"; # lexical variable
our($VERSION) = 5.31;# dynamic variable in current package
$this *= 7; # illegal; variables must be
# declared lexical or dynamic
my($arg1, $arg2) = @_; # lexical (traditional for a subroutine)
{
no strict 'vars'; # or something new
$quick = 7; # legal in this scope =
# dynamic variable in current package
$quick *= $main::var;
print "$quick\n";
}
$package::count++; # always legal (I presume?)
=head2 Alternative
Although the implementation above is currently considered to be the
best, an alternative would allow undeclared lexical variables. In
this approach, C would become C,
requiring declaration of all variables. Without C,
undeclared variables would be considered to be lexical, or variables
could be declared dynamic with C or some other syntax.
This approach would require more complexity in Perl5 -> Perl6
translation and be a much larger step in a new direction for the
language. Since the state-of-the-practice of Perl5 programming has
evolved to generally include C, it makes more sense to
simply make that the default than to modify the language any further.
=head1 REFERENCES
The section on "Private Variables via my()" in the perlsub manpage.
The Camel book.
RFC 18 (v1) Immediate subroutines
=head1 TITLE
Immediate subroutines
=head1 VERSION
Maintainer: Jean-Louis Leroy
Date: 04 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 18
=head1 ABSTRACT
This very simple construct, inspired by the Forth language, makes the
parser extensible by Perl code, providing powerful macro capabilities,
multi-line comments, inline functions and conditional compilation.
=head1 DESCRIPTION
When the parser sees a subroutine that has been marked as 'immediate',
it calls it immediately. The call's arguments are implicitly quoted as
with q{} and the resulting strings are passed to the subroutine. The
entire call is removed from the parse stream and replaced with the
subroutine's return value.
=head1 SYNTAX
use immediate qw( compileif ); # mark subroutines as immediate
=head1 EXAMPLES
# multiline comments
sub comment
{
return '';
}
use immediate 'comment';
sub foo
{
# ...
comment {
this is a multiline comment;
the call to comment is executed at parse time
and returns an empty string that replaces
the whole call in the parse stream };
}
# conditional compilation
sub compileif
{
my ($condition, $body) = @_;
return eval($condition) ? $body : '';
}
use immediate qw( compileif ); # mark subroutines as immediate
sub bar
{
compileif -e 'state'
{
do 'state';
}
compileif $Module::VERSION > 1.23,
{
# blah blah blah
}
}
# macros
sub square
{
my $arg = shift;
my $gensym = $arg . '_';
$gensym .= '_' while $arg =~ /$gensym/;
return "do { $gensym = $arg; $gensym * $gensym }";
}
=head1 IMPLEMENTATION
A flag is associated with the data structure associated to a
subroutine by the parser. The pragmatic module 'immediate' is used to
turn the flag on. When the parser recognizes a subroutine call, it
checks the flag and if it's true, proceeds as described above.
=head1 REFERENCES
The Forth standard.
"Starting Forth", by Leo Brodie
RFC 19 (v1) Rename the C operator
=head1 TITLE Rename the C operator =head1 VERSION Maintainer: J. David Blackstone <[EMAIL PROTECTED]> Date: 4 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 19 =head1 ABSTRACT The C operator of Perl5 and earlier does not do what it claims to and should be renamed. =head1 DESCRIPTION New Perl programmers are often confused by the behavior of the C operator, especially since a great deal of old educational material exists showing the obsolete practice of using C to create subroutine arguments and local variables. C does not provide variables that are local to the enclosing scope. Instead it permits what is known as dynamic assignment, the ability to temporarily assign a value to a variable such that the variable's original value will be restored when the current scope is exited. Relying on this mechanism to provide what most people think of as local variables (lexical scoping) can sometimes fail. C is useful in many cases and should be retained but renamed to reflect its action. =head1 IMPLEMENTATION Many replacement names have been proposed for local on the perl6-language list, and I am sure there are others that were proposed on p5p in earlier days. My current favorite name is C to reflect that a variable will undergo dynamic assignment. I am certain that better alternatives exist and that very few people will like that suggestion. A list of other proposed replacement names includes (but is not limited to, since I certainly have forgotten some): C (to reflect the fact that the variable's old value is pushed onto a stack and popped off when the scope containing the use of the operator is exited) C C C (not a good idea, in my opinion. I think that means making an exact copy of an object.) C C C C C C C C C C C C C C C (I'm not sure this was a proposal) None of these completely satisfies me, at the moment, and there does not appear to be any consensus among the group. =head1 REFERENCES The perlfunc manpage
RFC 20 (v1) Overloadable && and ||
=head1 TITLE
Overloadable && and ||
=head1 VERSION
Maintainer: Jean-Louis Leroy
Date: 04 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 20
=head1 ABSTRACT
It should be possible to overload && and ||, for this has very
legitimate uses.
=head1 DISCUSSION
The reason often cited for not allowing the overloading of logical
junctions (i.e. && and ||, LJ for short) is that LJs are
'short-circuiting' operators, iow the second argument is not always
evaluated. User-defined LJs cannot benefit from this feature, and
making it possible to overload LJs would only result in confusion.
There are two arguments to the contrary.
Even without the conditional evaluation feature, there are
very legitimate uses for overloaded LJs. The arguments are not always
Perl expressions - they may be objects that participate in - for
example - abstract syntax trees.
An example of this can be found in Tangram, a persistence
facility. The following Perl code:
my $p = $storage->remote('NaturalPerson');
@results = $storage->select($p,
$p->{age} > 10 & $p->{age} < 20);
...gets translated to the following SQL code:
SELECT t1.id, t1.classId, t1.country, t1.address,
t2.age, t2.partner, t2.first_name, t2.name
FROM Person t1, NaturalPerson t2
WHERE (t2.age > 10 AND t2.age < 20) AND t2.id = t1.id
Note that the 'short-circuiting' behavior does occur, in a way: on the
database side. Also note that '&' has to be used instead of '&&',
because the latter is not overloadable. Using the more intuitive '&&'
silently results in incorrect code.
The second argument why overloadable LJs should be supported is that
it seems possible to make them enjoy the conditional evaluation of the
built-in LJs. When the compiler sees code like:
expr1 && expr2
...and detects that the LJ is overloaded, it could replace it with:
user_defined_and( sub { $expr1 }, sub { $expr2 } )
The user-defined '&&' can thus decide whether or not to evaluate its
operands, for example:
sub user_defined_and
{
# mimic built-in operator &&
my ($left, $right) = @_;
if (my $result = $left->())
{
return $result;
}
return $right->();
}
RFC 17 (v1) Organization and Rationalization of Perl
=head1 TITLE
Organization and Rationalization of Perl State Variables
=head1 VERSION
Maintainer: Steve Simmons <[EMAIL PROTECTED]>
Date: 3 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 17
=head1 ABSTRACT
Perl currently contains a large number of state and status variables.
Some of these are (or should be deprecated), and the naming methods for
the rest are obscure. Since we are (potentially) adding, removing, and
changing the functionality of these vars with Perl6, we should seize the
opportunity to rationalize the names and organization of these variables
as well. These variables need to be made available with mnemonic names,
categorized by module, be capable of introspective use, and proper
preparation made for deprecation. A partial backwards compatibility
mechanism is suggested.
=head1 DESCRIPTION
Perl allows for the runtime examination and setting of a number of
variables. These existing C<$> vars are horrible names and
really need some cleanup and syntactic sugar. Different variables
have different problems, with some having one or more of the
following problems:
=over
=item *
unused (as far as we know)
=item *
useless, but still appear in older programs
=item *
duplicated by other features
=item *
standing in the way of advance because of backwards compatibility
=back
In the pre-rfc discussion of this issue, it was also pointed out
that these variables are hard to deprecate without nagging the crap
out of users running the programs. The proposed solution was
broadly applicable, and has been spun off into RFC 3.
The use of the C module is an attempt to solve the anti-mnemonic features
of these variables. A better solution is to do it right in the
first place, with a number of attendant wins:
=over
=item *
no need for Yet Another Module to be loaded
=item *
promotes code readability
=item *
probably promotes core Perl maintainability
=item *
grouping sets of variables together by function gives
the code writer strong hints as to variables that might
affect each other
=item *
should we move formats (or any similar current core functionality)
to a loadable module, this neatly encapsulates all the data with
a single referenced name
=item *
solves problems with C<$> variable proliferation
=item *
potentially promotes introspection - see below.
=back
In addition, many features which are now (re)set by other calls should
set appropriate state variables as well. Thus a perl script which
contains:
use strict foo;
might set a var C<$PERL_STRICT{foo}>, and so forth (this is probably
a poor example).
Credit where it is due: the idea of putting related values together into
an appropriately tagged hash is shamelessly ripped off from common C usage.
=head2 Advantages and Non-Loses
=head2 Clean Backwards Compatibility
To promote backward compatibility, one could write a C
module which would alias the old names to the new ones. That Would Be
Wrong, but someone will probably do it - so it may as well be us.
Obviously we cannot provide backwards compatibility for a variable
whose meaning has changed or which has vanished, but most of the
rest can be captured cleanly.
=head2 Promoting Removable Core Modules
It has been strongly proposed that `core perl' be broken down internally
into a number of modules such that one could build smaller or larger
custom perls. This feature would ease that work, and possibly set a
standard for how well-behaved non-core modules should implement such
things.
=head2 Provide Possible Guidelines To Core-able Modules
The discussion of removable core modules has strongly implied (sometimes
explicitly stated) that sites could take modules which are not currently
in the core and move them there. Having a standard which those modules
could follow for variable setting and exposure would be a major win.
=head2 Disadvantages
Literally none have been broached on the various C mailing lists.
=head2 Other Possible Features
It has been suggested by Alan Burlison <[EMAIL PROTECTED]>
that this allow for localizable settings. Thus module A might
turns warnings off when its features are in use, while module
B is unaffected by the setting done by module A. This is a change
in the functionality of such settings, and has the potential for
broadly changing what happens in perl. I suggest that this
issue is actually independent of how the variables are named,
and should be taken to another RFC if anyone is interested.
=head1 IMPLEMENTATION
=head2 Internal Implementation
The internal representation of these is largely irrelevant(!).
This RFC prescribes what the I interface looks like;
the implementation team should select whatever mechanism they
prefer for internal use. It's probably a maintenance win if
the same is used, but the proposers don't intend to dictate
to the developers.
=head2 External Implementation
Variables should be sorted into functional areas which ma
RFC 30 (v1) STDIN, STDOUT, and STDERR should be rena
This and other RFCs are available on the web at http://tmtowtdi.perl.org/rfc/ =head1 TITLE STDIN, STDOUT, and STDERR should be renamed =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 04 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 30 =head1 ABSTRACT Consensus has been reached that filehandles (currently barewords) will be renamed to use the leading $ type, to make them consistent with Perl. STDIN, STDOUT, and STDERR should follow suit and be renamed $STDIN, $STDOUT, and $STDERR. =head1 DESCRIPTION Currently, filehandles are barewords, such as FILE and PIPE. However, for Perl 6 these are planned to be renamed to true "single-whatzitz" types (thanks Tom) and prefixed with a $. So, the current: print FILE "$stuff\n"; Will become something like: print $fh "$stuff\n"; STDIN, STDOUT, and STDERR need to follow suit. We should change print STDERR "$stuff\n"; to: print $STDERR "$stuff\n"; This makes them consistent with other Perl variables, such as @ARGV, %INC, $VERSION, etc, all of which have the correct distiguishing prefix for their type. =head1 IMPLEMENTATION All references to STDIN, STDOUT, and STDERR will have to be changed. We may also want to consider making them readonly. Consider the implications of: $STDOUT = $fh; print "$stuff\n"; This would potentially have the same effect as current: select($fh); print "$stuff\n"; Perhaps we want this behavior, it is pretty cool. But maybe we don't. =head1 REFERENCES RFC14, Modify open() and opendir() to return handle objects
RFC 34 (v1) Angle brackets should not be used for fi
This and other RFCs are available on the web at
http://tmtowtdi.perl.org/rfc/
=head1 TITLE
Angle brackets should not be used for file globbing.
=head1 VERSION
Maintainer: Jon Ericson <[EMAIL PROTECTED]>
Date: 4 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 34
=head1 ABSTRACT
Angle brackets have two separate meanings in Perl - file globbing and
line input from a filehandle. This means that perl attempts to Do What
I Mean and often misinterprets me. Since file globbing can be
accomplished with the glob function and since file input is the more
common use of angle brackets, they should not be used for file globbing.
=head1 DESCRIPTION
=head2 Background
>From perlop/"I/O Operators":
If angle brackets contain is a simple scalar variable (e.g.,
<$foo>), then that variable contains the name of the
filehandle to input from, or its typeglob, or a reference to the
same. For example:
$fh = \*STDIN;
$line = <$fh>;
If what's within the angle brackets is neither a filehandle nor a simple
scalar variable containing a filehandle name, typeglob, or typeglob
reference, it is interpreted as a filename pattern to be globbed, and
either a list of filenames or the next filename in the list is returned,
depending on context. This distinction is determined on syntactic
grounds alone. That means C<< <$x> >> is always a readline() from
an indirect handle, but C<< <$hash{key}> >> is always a glob().
That's because $x is a simple scalar variable, but C<$hash{key}> is
not--it's a hash element.
One level of double-quote interpretation is done first, but you can't
say C<< <$foo> >> because that's an indirect filehandle as explained
in the previous paragraph. (In older versions of Perl, programmers
would insert curly brackets to force interpretation as a filename glob:
C<< <${foo}> >>. These days, it's considered cleaner to call the
internal function directly as C, which is probably the right
way to have done it in the first place.) For example:
while (<*.c>) {
chmod 0644, $_;
}
is roughly equivalent to:
open(FOO, "echo *.c | tr -s ' \t\r\f' '\\012\\012\\012\\012'|");
while () {
chop;
chmod 0644, $_;
}
except that the globbing is actually done internally using the standard
C extension. Of course, the shortest way to do the above
is:
chmod 0644, <*.c>;
A (file)glob evaluates its (embedded) argument only when it is
starting a new list. All values must be read before it will start
over. In list context, this isn't important because you automatically
get them all anyway. However, in scalar context the operator returns
the next value each time it's called, or C when the list has
run out. As with filehandle reads, an automatic C is
generated when the glob occurs in the test part of a C,
because legal glob returns (e.g. a file called F<0>) would otherwise
terminate the loop. Again, C is returned only once. So if
you're expecting a single value from a glob, it is much better to
say
($file) = ;
than
$file = ;
because the latter will alternate between returning a filename and
returning false.
It you're trying to do variable interpolation, it's definitely better
to use the glob() function, because the older notation can cause people
to become confused with the indirect filehandle notation.
@files = glob("$dir/*.[ch]");
@files = glob($files[$i]);
=head2 Areas of confusion
=over
=item Complex filehandle references
my %filesystem;
my $filename = '/etc/shells';
open $filesystem{$filename}, $filename
or die "can't open $filename: $!";
print <$filesystem{$filename}>;
__END__
GLOB{0xa042284}
=item Simple file glob variables
my $fileglob = '/etc/sh*';
print <$fileglob>;
__END__
[nothing printed]
=item Why don't these have the same output?
$ perl -e 'print '
/etc/shells
$ perl -e 'print <>' /etc/sh*
/bin/sh
/bin/bash
=back
=head2 The glob function exists
Now that we have a function interface to file globbing, why do we need
the obscure operator interface?
=head2 The readline meaning is more common
Angle brackets are a shortcut for either glob() or readline(). If we
are going to eliminate one meaning, it should be the less common
meaning.
=head1 IMPLEMENTATION
Remove the file-globbing behavior of the angle brackets.
=head1 REFERENCES
perlop/"I/O Operators", perlfunc/glob, perlfunc/readline
RFC 10 (v2) Filehandles should use C<*> as a type pr
This and other RFCs are available on the web at
http://tmtowtdi.perl.org/rfc/
=head1 TITLE
Filehandles should use C<*> as a type prefix if typeglobs are eliminated.
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 4 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 10
=head1 ABSTRACT
Version 1 of this RFC stated: "The lack of a type-defining punctuation
character prefix for filehandles makes them second-class variables in Perl.
If typeglobs are eliminated in Perl 6, the C<*> character would become
available as a type prefix character and could be used for filehandles."
Version 2 withdraws this request, contingent upon the removal of bareword
filehandles in Perl 6. If scalars or objects in scalars (C<$fh>) are used
for filehandles everywhere then there is no need to make a new type out of
them. The rest of the original RFC is left below for archival purposes.
=head1 DESCRIPTION
To pass filehandles around one either has to use a typeglob (C)
or put them in a scalar (C or the 5.6 C), at which point you can't tell that they're filehandles without the
right context.
There have been serious proposals to eliminate typeglobs in Perl 6. If they
get axed, the C<*> character could be reused for another datatype and the
filehandle is fortuitously closely related.
The mental jump is fairly small, since most people other than module
developers only ever saw C<*> used for filehandles anyway:
local *FH;
open (FH, ...);
This proposal would change that to
open (my *fh, ...);
=head1 IMPLEMENTATION
Backwards compatibility takes a hit unless the current filehandle syntax is
grandfathered in; I am not taking a position on whether it should be. Since
it is contingent upon typeglobs being eliminated, it won't break any
existing code that already uses typeglobs that won't be broken anyway.
Use of Cs will now look like
while (<*fh>) { ...
which means that the use of the angle operator for globbing also has to go.
As if an excuse were needed.
This proposal also applies to directory handles.
=head1 REFERENCES
L
RFC 33 (v1) Eliminate bareword filehandles.
This and other RFCs are available on the web at http://tmtowtdi.perl.org/rfc/ =head1 TITLE Eliminate bareword filehandles. =head1 VERSION Maintainer: Peter Scott <[EMAIL PROTECTED]> Date: 4 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 33 =head1 ABSTRACT Now that scalars (objects) can be used for filehandles, the bareword form should be eliminated. =head1 DESCRIPTION The venerable bareword form of the filehandle leads to code that is unnecessarily abstruse given that they can now be stored in scalars. Bareword filehandles are not lexical, and require the use of typeglobs and C to pass them to subroutines, concepts unnecessarily advanced for such a beginner-type operation. =head1 IMPLEMENTATION Easy, hopefully. =head1 REFERENCES L
RFC 10 (v3) Filehandles should use C<*> as a type pr
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Filehandles should use C<*> as a type prefix if typeglobs are eliminated.
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Version: 3
Mailing List: [EMAIL PROTECTED]
Status: Retracted
Number: 10
=head1 ABSTRACT
Version 1 of this RFC stated: "The lack of a type-defining punctuation
character prefix for filehandles makes them second-class variables in Perl.
If typeglobs are eliminated in Perl 6, the C<*> character would become
available as a type prefix character and could be used for filehandles."
Versions 2 and 3 withdraw this request, contingent upon the removal of
bareword filehandles in Perl 6. If scalars or objects in scalars (C<$fh>)
are used for filehandles everywhere then there is no need to make a new
type out of them. The rest of the original RFC is left below for archival
purposes.
=head1 DESCRIPTION
To pass filehandles around one either has to use a typeglob (C)
or put them in a scalar (C or the 5.6 C), at which point you can't tell that they're filehandles without the
right context.
There have been serious proposals to eliminate typeglobs in Perl 6. If they
get axed, the C<*> character could be reused for another datatype and the
filehandle is fortuitously closely related.
The mental jump is fairly small, since most people other than module
developers only ever saw C<*> used for filehandles anyway:
local *FH;
open (FH, ...);
This proposal would change that to
open (my *fh, ...);
=head1 IMPLEMENTATION
Backwards compatibility takes a hit unless the current filehandle syntax is
grandfathered in; I am not taking a position on whether it should be. Since
it is contingent upon typeglobs being eliminated, it won't break any
existing code that already uses typeglobs that won't be broken anyway.
Use of Cs will now look like
while (<*fh>) { ...
which means that the use of the angle operator for globbing also has to go.
As if an excuse were needed.
This proposal also applies to directory handles.
=head1 REFERENCES
L
RFC 14 (v1) Modify open() and opendir() to return ha
=head1 TITLE
Modify open() and opendir() to return handle objects
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 2 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 14
=head1 ABSTRACT
Currently, open() and opendir() are given handle arguments, whose values
are twiddled if a filehandle can be created:
open(HANDLE, "<$filename");
open my $fh, "<$filename";
opendir DIR, $dirname;
In order to make these functions more consistent with other
constructor-like functions (i.e. new(), etc), they should be changed to
instead return the handle objects:
$fh = open "<$filename" or die;
$dh = opendir $dirname or die;
This would make these functions more internally consistent within Perl.
=head1 DESCRIPTION
First, this RFC assumes that filehandles will be $ (single-whatzit)
types, which seems to have reached an overall informal consensus.
As many have observed, the current filehandle mechanism is insufficient
and largely "a historial accident". The goal of the redesign of file
objects is to make them as flexible and powerful as other objects within
Perl. Since we are redesigning filehandles to be true fileobjects, we
should revise their "constructor" functions as well, returning file
objects instead of twiddling values on success.
As shown above, this would change the open() function to:
$fh = open "<$filename" or die;
If successful, open() and opendir() will return file and dir objects
(respectively). On failure, they will return undef. This still allows
the user the ability to test the return value of open() and opendir() by
checking for a "true" (handle) or "false" (undef) condition.
We get a couple benefits from this approach. First, these functions
could be further extended to accept or return additional arguments. For
example, we might decide that open() can return extra "interesting
stuff" in an array context.
($fh, @other_stuff) = open $filename;
Or, we might decide that open() should be able to bind classes similar
to tie(). This could give us easy access to methods that opened HTTPD,
FTP, SSH, or other connections:
$fh = open $filename, Class::Module;
If the "Class::Module" is not specified, then "IO::Handle" (or some
other suitable alternative) could be assumed. I know this looks alot
like tie(). I'm not claiming it's a great idea, it's just an idea of how
a more general open() could give us some key benefits.
Finally, if no file arg is specified to open(), opendir(), close(), or
closedir(), I would like to propose these should assume $_, to make them
that much more consistent within Perl. This would allow one to write
loops as such:
for (@filenames) {
my $obj = open;
push @open_handles, $obj;
}
# ... stuff happens ...
for (@open_handles) {
close;
}
Perhaps this specific example is ugly (and useless), but there are
probably many more situations in which one could take advantage of this.
=head1 IMPLEMENTATION
The open() and opendir() functions would have to be altered to take one
argument (not two) and return the corresponding file object or undef.
The close() and closedir() functions would remain unchanged, acting on
the file objects:
close $fh;
closedir $dh;
Unless the parts about assuming $_ and binding classes are accepted, in
which case these will have to be added.
RFC 48 (v1) Replace localtime() and gmtime() with da
e() object $t1 + 533; # returns date() object $t1 + $t2; # ?? I'm not sure why you would do the last one. With the current C it causes a runtime error, though, so if we want to support it we'll have to see how feasible it is. =head1 IMPLEMENTATION Slash and burn C and C. Actually, we should probably move them to C or some other place and keep them available, since some people like pain. :-) The C<$tz> variable might seem hard at first. It's not. There are only 2 possible values: 1. UTC or other timezone (user specified) 2. Local timezone (none specified) So, all that would have to happen is C would have to store the correct value in the return object, in the precendence above. Extensive date calculations, including reverse date calculations, should be left to an external module. =head1 REFERENCES Matt Sergeant's great Time::Object CPAN module http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-01/msg00241.html Jonathan Scott Duff, Tim Jenness, and perl6-language for their input
RFC 37 (v1) Positional Return Lists Considered Harmf
This and other RFCs are available on the web at http://tmtowtdi.perl.org/rfc/ =head1 TITLE Positional Return Lists Considered Harmful =head1 VERSION Maintainer: Jarkko Hietaniemi <[EMAIL PROTECTED]> Date: 04 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 37 =head1 ABSTRACT Perl has traditionally returned from various functions long (>2) lists of values. Some traditions are simply bad. =head1 DESCRIPTION Functions like stat() and get*ent() return long lists of mysterious values. The implementation is assumedly easy: just push some values out of C structs into the Perl return stack. Wrong. And once more, wrong. Firstly, who can remember which one of the stat() return values was the atime is or which is the 4th return value of localtime()? The perlfunc documentation makes this difficulty painfully obvious by having to list the indices alongside the values. Secondly, the current solution is seriously non-extensible. One cannot easily add new return values to the APIs because someone may be expecting an exact number of return values, or someone may be accessing the values by position from the end of the list Obsoleting values (or marking them as non-applicable to the current platform) has to be done by for examples returning undef. =head1 IMPLEMENTATION The solution is simple: return hashes instead of lists. Yes, one still has to know how the fields are named, so the proposed solution is still not perfect. =head1 REFERENCES perlfunc File::stat User::grent User::pwent
RFC 2 (v1) Request For New Pragma: Implicit
=head1 TITLE Request For New Pragma: Implicit =head1 VERSION Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]> Date: 01 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 2 =head1 ABSTRACT Perl 6 should add a new pragma called C. =head1 DESCRIPTION I am lazy. I am spoiled by the implicit $_. I like the implicit $_. Implicit $_ good. Ugh. I also came to the sysadm / programming world in a long, circuitous route. I never programmed with toggle switches. I've never seen a punch card. My first programming was in Commodore 64 Basic. C64 Basic. No safe-signals there, either. ;) It did have one good thing, though. One very useful thing, for lazy people like me. C could be written like C. It just rolled off the fingers. C<10 ?"Port Perl for the 64!">. Of course, those days have gone. I've seen the light. I'm a *nix head and JAPH. But how I still hate typing out print. Particularly because I do it so much. Oh, sure, I could play games with HERE docs and the ilk, but I'm too lazy. But I digress. There should be an C pragma that gives new life and meaning to void context constructs. In my case, I want it to print to the default filehandle, (which is also implicit, I might add.) Scoping needs to be tightly controlled, of course. Don't want someone else's void context to show up on your display, now do you? And, of course, it would be defaulted to off. It could continue to ignore constant 0s and 1s. (But those pre-pod embedded comment strings just B to go.) Ideally, I'd like to use it for printing, but I suppose some other lazy person may want to use it for something else. =head1 MOTIVATORS Laziness, pure and simple. =head1 IMPLEMENTATION The front-end would have to detect void usage and either arrange to have the results passed to a callback, (in which case, would you know what wantarray() wants to know?) or inject the appropriate term in the optree. =head2 SUMMARY OF IMPLEMENTATION I've no real concrete ideas on this, sorry. =head2 IMPACT =over 4 =item * Impact on Perl 5. Mutual compatibility between Perl 5 and Perl 6, with the exception of C and the sematics it would add. (Obviously, other changes to the language notwithstanding.) =back =head2 UNKNOWNS =over 4 =item * What about subs? Backticks? Things that return meaningless printable information, like system()? C would put it on the user. After all, he doesn't have to use it. =item * Would C<;> print the contents of $_ to the default filehandle? ;-) =back =head1 REFERENCES None, currently.
RFC 3 (v1) messages.rfc - An RFC to discussing the
=head1 TITLE
messages.rfc - An RFC to discussing the wisdom of allowing run time error
and warning messages to be modified at run time
=head1 VERSION
Maintainer: Corwin Brust <[EMAIL PROTECTED]>
Date: 1 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 3
=head1 ABSTRACT
I'm probably wrong in this, but I rather think this one's explains it self.
I want perl's error (and warning) messages to be specific to each program I
write.
=head1 DESCRIPTION
I have, and I cannot assume I am alone in this, spent a fair amount of time
creating subroutines which trap various error responses from Perl, only to
turn right around and 'die' with an error message of my own, differing only
in the text shown when the program terminates.
Wouldn't it be great if we could just reword the existing error messages on
a per-script basis to be relevant to that program, and let Perl's normal
error handling mechanism do the work of presenting the user with the bad
news.
=head1 IMPLEMENTATION
It seems, as of this writing, that the means for accessing Perl internal
variables will not be as it has been.
Any method of allowing for program writer defined messages would have to be
closely time to whatever new mechanism we find agreeable. But...
$perl::core::err{TYPE_MISMATCH} = {
fatal => 1,
handler => sub {
my $arg = shift;
my $func = shift;
my $correct_type = shift;
my $sent_type = shift;
my $prog = shift;
my $line = shift;
my $near = shift;
CORE::die(qq[Type of
$arg to $func must be $correct_type (not $sent_type) at $prog line $line,
$near\n]);
},
}
Where CORE::die is able to look for a true value in
$perl::core::err{TYPE_MISMATCH}->{fatal} and either die or issue a warning
as appropriate.
And, yeah, I'm sure there's a B way to implement this. I hope,
however, that I have shown such a thing can be done.
=head1 REFERENCES
=cut
RFC 12 (v1) variable usage warnings
=head1 TITLE variable usage warnings =head1 VERSION Maintainer: Steve Fink <[EMAIL PROTECTED]> for now Date: 2 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 12 =head1 ABSTRACT "VARIABLE used only once: possible typo" should be replaced with warnings on uses of uninitialized variables (including lexicals). =head1 DESCRIPTION Perl6 should distinguish between uses and assignments to variables, and warn only when a variable is used without being assigned. In perl5 the complete program $x = 3 complains, but $x = 3; $x = 3 does not, nor does my $x = 3 nor use vars qw($x $y); $x = $z; $y = $z; It would be more useful to have a complaint for both lexical and package variables, and only when a variable is used without ever being assigned to (or having its reference taken). The warning for the purpose described in this RFC should be "use of uninitialized variable C<$x>". This message is too close to the existing "use of uninitialized value", but that message is badly phrased anyway, so it will change to "use of undefined value" to better reflect its actual meaning. (The two are related; "use of undefined value" can be thought of as encompassing the runtime counterpart to the compile-time "use of uninitialized variable" proposed here.) Note that if you currently depend on lexical variables having undefined values, you would need to change C to C. This is a Good Thing. =head1 IMPLEMENTATION I have no idea how difficult this would be to implement. You just need to distinguish between lvalue and rvalue uses of a variable, I guess? But hey, this is a language RFC, not an internals RFC. :-) There's also the question of whether to properly track uses and definitions so that C<$::z = $x; $x = 3> is a warning, as well as C<$x = 3 if f(); print $x>. Though the latter would require renaming the warning to "possible use of uninitialized variable C<$x>".
RFC 8 (v1) The AUTOLOAD subroutine should be able t
=head1 TITLE The AUTOLOAD subroutine should be able to decline a request =head1 VERSION Maintainer: Leon Brocard <[EMAIL PROTECTED]> Date: 02 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 8 =head1 ABSTRACT In Perl 5, the first AUTOLOAD subroutine found in an object's heirachy is used and any other AUTOLOAD subroutines higher up are ignored. I propose that in Perl 6 we allow AUTOLOAD subroutines to decline a request, which allows other AUTOLOADs to cope with it. =head1 DESCRIPTION AUTOLOAD is a very useful and handy way to handle cool and exciting things, but as has been pointed out many times before, only one AUTOLOAD can be called in the object's heirachy, even if multiple ones exist. This is due to the fact that AUTOLOAD subroutines must do something - they can not currently decline a request. I propose one of the methods which has previously been discussed on p5p. =head1 IMPLEMENTATION Instead of calling the right thing or actually doing the right thing, AUTOLOAD subroutines should return a coderef which will be run as if it were the method called. If an AUTOLOAD subroutine does not wish to cope with a method call, it should return undef. Perl would then walk the OO heirachy and find the next AUTOLOAD to call, eventually failing with an error if no AUTOLOAD method is found which will accept the call. =head2 $AUTOLOAD While we're at it, it may be a good idea to remove the global $AUTOLOAD variable and instead pass it as the first parameter of the AUTOLOAD subroutine call. =head1 REFERENCES Some posts on p5p which I've yet to find again.
RFC 6 (v1) Lexical variables made default
=head1 TITLE Lexical variables made default =head1 VERSION Maintainer: J. David Blackstone <[EMAIL PROTECTED]> Date: 1 August 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 6 =head1 ABSTRACT Prior to version 5, all implementations of Perl were designed with only dynamic variables in mind. Perl5 provided lexical variables in a backward compatible way. Perl6 should make lexical variables the default. =head1 DESCRIPTION Dynamically-scoped variables can have many effects which are counterintuitive and undesirable. In Perl5, lexically-scoped variables are available with the C operator, meaning the programmer has to go to extra lengths to use this feature. There are very few circumstances in which dynamic variables have a distinct advantage over lexicals. In Perl6, every variable should be lexical unless otherwise specified. Variables should only be visible within the scope in which they are defined (the enclosing block, method, or file). Dynamic variables and the misnamed C operator should still be permitted in Perl6, but extra syntax should be required to specify a variable as dynamic, just as Perl5 currently requires analogous extra syntax for lexical variables. =head1 IMPLEMENTATION I don't know enough about internals to say anything about implementation from that standpoint, but I believe a few words are in order as to how this should look in the language. =head2 Lexical variables Any variable should automatically be lexical. The C keyword could still be used in order to declare a variable, along with a C pragma or something analogous to force declaration of all variables. As an example, the following variables are lexical: $number = 15; my $string = "foo"; $obj = Class->new(); my Dog $spot = new Dog(); The final line may or may not be a part of Perl6 syntax, as decided elsewhere. =head2 Dynamic variables Dynamic variables would have to be specifically declared. Perl5 currently uses the C pragma to declare dynamic variables, as well as the C keyword. (XXX Someone help me out; C didn't work the way I expected, and I still don't understand it because I haven't had time to learn. :( ) Perl6 could choose a pragma or keyword to declare dynamic variables. The C operator should be retained due to its usefulness for dynamic scoping, but should be renamed to avoid confusion. I'm currently suggesting a name of C. More euphonious suggestions are requested. This RFC needs to include some specific examples of syntax used to declare dynamic variables, as soon as such syntax is finalized. =head1 REFERENCES The section on "Private Variables via my()" in the perlsub manpage. The Camel book.
RFC 4 (v1) type inference
=head1 TITLE
type inference
=head1 VERSION
Maintainer: Steve Fink <[EMAIL PROTECTED]>
Date: 1 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 4
=head1 ABSTRACT
Types should be inferred whenever possible, and optional type qualifiers
may be used to gain whatever level of type stricture desired.
=head1 DESCRIPTION
For large systems, and often for small ones, type checking is
extremely valuable as a way of eliminating bugs at compile time and
avoiding errors while making global changes. I propose that we create
a type hierarchy, such as
any
list
list(T)
hash
hash(T -> T)
scalar
reference
ref(T)
nonref
number
integer
void
(This is just a sketch; there are many ways of skinning this cat.)
By default, only constants would be assigned a type. Every node in the
parse tree would be assigned a type. Variables would not have a single
type; they would have a possibly different type after every
assignment. So using the default rules
1 $x = 3;
2 $x .= "x";
3 $h{$x} = \$x;
4 $h{foo} = "bar";
5 $x = f();
I<$x> would have type C after line 1 and C after
line 2. I<%h> would have type C<< hash(nonref -> ref(nonref)) >> after
line 3, and then would find the nearest ancestor in the next line,
resulting in C<< hash(nonref -> scalar) >>. Line 5's effect depends on
whether C's type is known. If not, then I<$x> will have type
C after line 5.
Notice that so far, all existing programs will always typecheck
successfully, so no burden has been placed on the programmer who does
not want types.
Now say we insert C at the beginning of the example
(or some other syntax). That means that we are asserting that I<$x>
will I be of type C, and we will flag a type error on
line 2 and an optional warning on line 5 if the return type of C
in scalar context is unknown.
Note that error messages are only generated when two things with
strong types collide. So C will not
complain, but C will.
(I am leaving out a lot of details, such as what happens to the type
of I<%h> if just after line 3 you say C<$x = [[]]>. Or what happens to
the types of all accessible variables on an eval"", or function types,
or a hundred other messy problems. But even if lots of stuff gets
promoted to type C, I still think that types will be very useful
within individual subroutines and other isolated areas.)
=head1 IMPLEMENTATION
I propose not changing runtime behavior at all; in the case of
C, I<$x> may actually end up containing a
non-integral string with no warning issued. If you want a warning,
write your own RFC. ;-)
Implementation for the most part is straightforward type inference
using unification. The wrinkles come in from how complicated the type
hierarchy is, and where we want to place the balance between false
positives and false negatives. (Type theorists do not allow false
negatives, but I'm not a type theorist and their motivation for that
stance is allowing safe run-time behavioral differences.)
RFC 7 (v1) Higher resolution time values
=head1 TITLE Higher resolution time values =head1 VERSION Maintainer: Gisle Aas <[EMAIL PROTECTED]> Date: 2000-08-02 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 7 =head1 ABSTRACT All functions that return time values (seconds since epoch) should use floating point numbers to return as much precision as the platform supports. All functions that take time values as arguments should work for fractional seconds if the platform supports it. =head1 DESCRIPTION Perl5 only support 1 second resolution on time values. In order to get higher resolution timing an external module (Time::HiRes) currently need to be used. This situation ought to be improved in perl6. All functions that return time values (seconds since epoch) should use floating point numbers to return as much precision as the platform supports. This include the following builtin functions: time stat/* atime, mtime and ctime fields */ times /* already float */ All functions that take time values as arguments should work for fractional seconds if the platform supports it. This include the following builtin functions: sleep alarm utime One problem with using doubles to represent time values is that it will not always be able to represent all of the time precision that the platform actually support. For instance time() value with Unix epoch represented with 15 decimal digit float precision will only support around 10 µs resolution for current timestamps. =head1 IMPLEMENTATION Should be straight forward. Configure might need to figure out some more about what hires-timer interfaces are available if it does not already do this. =head1 PERL5 PORTABILITY Calls to time() could be transformed to int(time()) when converting perl5 programs to perl6. =head1 REFERENCES Time::HiRes module on CPAN
RFC 16 (v1) Keep default Perl free of constraints su
=head1 TITLE Keep default Perl free of constraints such as warnings and strict. =head1 VERSION Maintainer: Daniel Chetlin <[EMAIL PROTECTED]> Date: 3 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 16 =head1 ABSTRACT Perl5 is usable with no hassle as a quick-and-dirty problem-solver by default. It is ideal for one-liners, short scripts, and quick hacks that have no need for extra protection or error-checking. It is also great for large projects by making use of the C and C pragmas. Perl6 should not make the one-liners, short scripts and hacks need to jump through extra hoops to get the "lax" behaviour which is default in Perl5; the point of using Perl as a quick-and-dirty tool is that you don't have to do anything extra. =head1 DESCRIPTION Perl provides two main ways to ensure "safer", cleaner, more maintainable code: the C<-w> switch/C pragma and the C pragma. It appears likely that Perl6 will improve upon, expand, or add to this area. Extra functionality and power for these pragmas as well as additional pragmas (such as the C pragma mentioned at TPC) seem to be a good thing, but none should become default for Perl. In large projects which require the constraining pragmas, it is not an issue to take the extra steps and 'use' them. But in quick solutions and one-liners, it is a major drawback to have to add C or C<-M-strict> for every quick hack or one-liner that would violate the C pragma. Some have suggested a shortcut command-line switch that would disable the constraining pragmas, and others have suggested that one-liners be exempt from the default. Both of these solutions would make things somewhat better, but it still does not fit what seems to have been the philosophy of Perl from day 1: be _lax_ by default, and allow constrictions to be added by hand. Perl6 is intended to make the easy things easier and the hard things possible, just like Perl5 only moreso. While making the constraining pragmas the default might make hard things very slightly more possible, it would also make lots of easy things harder, and that is something to avoid at all costs. This RFC is particularly concerned with the idea of having C on by default. This is an attempt to get around Perl's design of having all variables global by default, and lexical only when declared. It seems that a much better solution would be to redefine Perl's default behaviour in the case of undeclared variables, and cause those to be lexical. Making C default appears to be an attempt to fix a hole in the floor by permanently barring access to the room in which the hole is, rather than just patching the hole. =head1 IMPLEMENTATION There should be no implementation issues. =head1 REFERENCES perlrun(1), strict(3)
RFC 21 (v1) Replace C with a generic C
=head1 TITLE
Replace C with a generic C function
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 August 2000
Version: 1.00
Mailing List: [EMAIL PROTECTED]
Number: 21
=head1 ABSTRACT
This RFC proposes to extend the number of detectable calling contexts
and replace the limited (and misnamed) context detection of C
with a more precise and general mechanism.
=head1 DESCRIPTION
C>
C takes a list of strings that describe aspects of the context in
which the current subroutine has been called. It returns a list
indicating whether or not the current subroutine's call context matches
all the aspects specified in the list. If some aspect of the context
does not match the argument list, the entire C fails and
an empty list is returned. Otherwise, a list of at least one integer
element is returned.
That integer (the "expectation count") indicates the number of return
values expected by the context. For void contexts, the expectation count
is always zero; for scalar contexts, it is always zero or one; for array
contexts it may be any non-negative number.
If the context is expecting an unspecified number of return values
(typically because the result is being assigned to an array variable),
the expectation count is the largest representable integer (C<~0>).
If C is called in a scalar hashref context without arguments, it returns a
reference to a hash whose keys are all aspects that are currently true.
If C is called in any other context without arguments, it returns a
list consisting of the expectation count, followed by all aspects that
are currently true.
The various aspects that may be specified are:
=over 8
=item 'LVALUE'
The subroutine call is being used as an lvalue:
func() = 0;
=item 'RVALUE'
The subroutine call is being used as an rvalue:
$val = func();
@vals = func();
=item 'LIST'
The subroutine was called in a list context:
@vals = func();
print func();
=item 'SCALAR'
The subroutine was called in a scalar context:
$val = func();
=item 'VOID'
The subroutine was called in a void context:
func();
=item 'HASH'
The subroutine was called in a context where its return value is
assigned to (or treated as???) a hash:
%hash = func();
@keys = keys func();# ???
=item 'STRING'
The subroutine was called in a stringifying context:
$val = $hash{func()};
print func();
=item 'NUMBER'
The subroutine was called in a numerifying context:
$val = func() * 2;
$val = sin(func());
=item 'INTEGER'
The subroutine was called in a numerifying context that
requires an integer:
$val = $array[func()];
$val = "str" x func();
=item 'BOOLEAN'
The subroutine was called in a boolean context:
if ( func() ) {}
$val = func() || 0;
$val = func() or die;
=item 'SCALARREF'
The subroutine was called in a context that expects a scalar reference:
$val = ${func()};
=item 'ARRAYREF'
The subroutine was called in a context that requires an array reference be returned:
func()->[$index];
push @{func()}, $val;
=item 'HASHREF'
The subroutine was called in a context that requires a hash reference be returned:
func()->{key};
@keys = keys %{func()};
=item 'OBJREF'
The subroutine was called in a context that requires an object reference be returned:
func()->method();
=item 'CODEREF'
The subroutine was called in a context that requires a code reference be returned:
func()->();
&{func()}();
=item 'IOREF'
The subroutine was called in a context that requires a filehandle reference be
returned:
print {func()} @data;
=item I
The subroutine was called in a context that would like to see an object of the named
class returned:
my Dog $spot = func(); # want 'Dog' returns true
=back
=head2 Example
our ($data, @data) ;
sub lastdata : lvalue {
if ($DEBUG)
{
my ($expcnt,@aspects) = want;
print "lastdata called in @aspects context\n";
print "expected $expcnt return values\n";
}
return if want->{VOID};
return $dataif want qw(LVALUE SCALAR);
return "$data" if want 'SCALAR', 'STRING
return eval{$data+0}||0 if want 'SCALAR', 'NUMBER';
return $dataif want 'SCALAR', 'BOOLEAN';
if (my ($count) = want 'LIST')
{
return @data if $count > @data;
return @data[0..$count-1];
}
}
=head2 Listing of possible context combinations:
within &func, &want returns:when:
=
(0, VOID, RVALUE
RFC 22 (v1) Builtin switch statement
=head1 TITLE
Builtin switch statement
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 August 2000
Version: 1.00
Mailing List: [EMAIL PROTECTED]
Number: 22
=head1 ABSTRACT
This RFC proposes a syntax and semantics for an explicit case mechanism for
Perl. The syntax is minimal, introducing only the keywords C and
C and conforming to the general pattern of existing Perl control
structures. The semantics are particularly rich, allowing any one (or
more) of nearly 30 forms of matching to be used when comparing a switch
value with its various cases.
=head1 BACKGROUND
In seeking to devise a "Swiss Army" case mechanism suitable for Perl,
it is useful to generalize the switch/case notion of distributed conditional
testing as far as possible. Specifically, the concept of "matching"
between the switch value and the various case values need not be
restricted to numeric (or string or referential) equality, as it is in other
languages. Indeed, as Table 1 illustrates, Perl
offers at least sixteen different ways in which two values could
generate a match.
=head2 Table 1: Matching a switch value (C<$s>) with a case value (<$c>)
Switch CaseType of Match Implied Matching Code
Value Value
== = = =
number I numeric or referential C
or ref equality
other other string equality C
non-ref non-ref
scalar scalar
string regexp pattern match C
array scalar array entry existence C=$c && $cE@$s;>
ref array entry definition C[$c];>
array entry truth C[$c];>
array array array intersection C
ref ref (apply this table to
all pairs of elements
C<$s-E[$i]> and
C<$c-E[$j]>)
array regexp array grep C
ref
hashscalar hash entry existenceC{$c};>
ref hash entry definition C{$c};>
hash entry truthC{$c};>
hashregexp hash grep C
ref
sub scalar return value definition C($c);>
ref return value truth C($c);>
sub array return value definition C(@$c);>
ref ref return value truth C(@$c);>
In reality, Table 1 covers 29 alternatives, because only the equality and
intersection tests are commutative; in all other cases, the roles of
the C<$s> and C<$c> variables could be reversed to produce a
different test. For example, instead of testing a single hash for
the existence of a series of keys (C{$c}>),
one could test for the existence of a single key in a series of hashes
(C{$s}>).
As L observes, a Perl case mechanism must support all these
"ways to do it".
=head2 DESCRIPTION
Adding a switch statement would require two new control structures:
C and C. The C statement takes a single
parenthesized argument (the "switch value") of any scalar type,
including any reference type. A C or C pattern may also
be specified and is automagically converted to a C. A hash or array
may also be specified and is automatically enreferenced.
Regardless of the type of argument, its value is stored as the
current switch value in an inaccessible localized control variable.
The switch value is followed by a block, which may contain any statements,
including zero or more C statements.
The C statement takes a single scalar argument (which need be parenthesized
only if it's a variable), followed by a block.
The C statement selects the
appropriate type of matching between that argument and the current switch value,
as determined by the respective types of the switch value and the C argument
(see Table 1). If the match is successful, the block associated
with the C statement is executed.
In most other respects, the C statement is semantically identical
to an C statement.
For example, a C statament can be followed by an C
clause, and can be used as a postfix statement qualifier.
However, once the block of any C statement finishes executing,
control is immediately transferred to the end of the enclosing C
statement. The same effect may be obtained by executing a C within
the block of the C. This means that, normally, there is no C-like
"fall-through" from a Perl C statement. For example:
my $val = 7;
switch ($val) {
case [0..9] { print "single digit\n" }
case [10..] { print "digits\n"; last }
case 7 { print "lucky seven!\n" }
}
would never print "lucky seven", since the first C will always
succeed and transfer control out of the C.
Howeverm it I possible to cause a C statement to "fall-through". If a
C is executed within a C block, control is immediately
transferred to the statement following the C
RFC 23 (v1) Higher order functions
=head1 TITLE
Higher order functions
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 August 2000
Version: 1.00
Mailing List: [EMAIL PROTECTED]
Number: 23
=head1 ABSTRACT
This RFC proposes some syntactic sugar to simplify the creation
of higher-order functions (a.k.a. "currying").
=head1 DESCRIPTION
One situation in which the proposed Perl C statement does not
provide a good substitute for a cascaded C, is where a switch value
needs to be tested against a series of conditions. For example:
sub beverage {
switch (shift) {
case sub{ $_[0] < 10 } { return 'milk' }
case sub{ $_[0] < 20 } { return 'coke' }
case sub{ $_[0] < 30 } { return 'beer' }
case sub{ $_[0] < 40 } { return 'wine' }
case sub{ $_[0] < 50 } { return 'malt' }
case sub{ $_[0] < 60 } { return 'Moet' }
else{ return 'milk' }
}
}
The need to specify each condition as an anonymous subroutine is
tiresome. Each of these small subroutines is really a "higher order"
function, which exists merely to bind the second operand of the
C> operator.
It is proposed that Perl reserve the bareword C<__> (underscore-underscore)
as a "placeholder" for generating higher order functions more cleanly.
That is, any expression containing C<__> anywhere that a value might
appear, will be converted to "deferred expression": a reference to a
subroutine in which the placeholders are replaced by the appropriate
number and sequence of arguments.
That is, the expression:
$check = __ < 2 + __ * atan($pi/__) or die __;
is equivalent to:
$check = sub (;) {
$_[0] < 2 + $_[1] * atan($pi/$_[3]) or die $_[4]
};
This could then be invoked:
$check->(@args);
It would also be possible to interpolate arguments into a static expression
like so:
(__ < 2 + __ * atan($pi/__) or die __)->(@args);
=head2 Examples:
With C<__>, the previous ugly case statements can be rewritten:
sub beverage {
switch (shift) {
case __ < 10 { return 'milk' }
case __ < 20 { return 'coke' }
case __ < 30 { return 'beer' }
case __ < 40 { return 'wine' }
case __ < 50 { return 'malt' }
case __ < 60 { return 'Moet' }
else { return 'milk' }
}
}
Likewise a Tree class might provide a traversal callback like so:
$root = Tree->new(load_from => "datafile")
my $sum = 0;
$root->traverse( $sum += __ );
Higher order functions would also be very useful with the proposed C function:
$sum = reduce __+__ (0,@vals);
$prod = reduce __*__ (1,@vals);
and with the new semantics of C:
@sorted = sort(__ cmp __, @list);
=head2 Re-currying deferred expressions
The subroutines generated by a placeholder are not exactly like the
equivalent subroutines shown above. If they are called with fewer than
the required number of arguments, they return another higher order
function, which now has the specified arguments bound as well.
Thus:
$check_or_die = $check->(@args[0..2]);
produces another deferred expression, one that requires only a single argument:
$check_or_die->("Error message");
Arguments other than the last can also be bound by the explicit use of
placeholders:
$check_n = $check->(__, @args[1..3]);
# and later...
$check_n->($n);
Thus the expression:
$check = __ < 2 + __ * atan($pi/__) or die __;
is actually equivalent to:
$check = sub (;) {
@_==0 ? __ < 2 + __ * atan($pi/__) or die __
: @_==1 ? $_[0] < 2 + __ * atan($pi/__) or die __
: @_==2 ? $_[0] < 2 + $_[1] * atan($pi/__) or die __
: @_==3 ? $_[0] < 2 + $_[1] * atan($pi/$_[1]) or die __
: $_[0] < 2 + $_[1] * atan($pi/$_[1]) or die $_[1]
;
};
Note that the level of currying for a deferred expression can always be
determined by looking at its prototype.
=head1 IMPLEMENTATION
Probably a pragma:
use __;
=head1 SEE ALSO
RFC for switch statement
RFC for reduce function
RFC 24 (v1) Semi-finite (lazy) lists
=head1 TITLE
Semi-finite (lazy) lists
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 August 2000
Version: 1.00
Mailing List: [EMAIL PROTECTED]
Number: 24
=head1 ABSTRACT
This RFC proposes that the right operand of a C<..> operator
may be omitted in a list context, producing a lazily evaluated
semi-finite list. It is further proposed that operations on
such lists also be carried out lazily.
=head1 DESCRIPTION
It is proposed that the right operand of a list context range operation
be made optional. If omitted, the resulting range would become semi-infinite:
for (1..) {
print "The next number is: $_\n";
}
@odds = grep { $_%2 } (1..);
switch ($n) {
case [32..] { print "Two many characters in filename" }
case (@odds){ print "That's odd!" }
}
Note that the values in @odds would also be lazily generated
(otherwise the C would never finish).
=head1 IMPLEMENTATION
Ask MJD.
=head1 SEE ALSO
RFC proposing a co-routine mechanism
=head1 REFERENCES
The thoughts and writings of Mark-Jason Dominus.
RFC 25 (v1) Multiway comparisons
=head1 TITLE
Multiway comparisons
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 August 2000
Version: 1.00
Mailing List: [EMAIL PROTECTED]
Number: 25
=head1 ABSTRACT
This RFC proposes that multiway comparisons such as:
if ( 0 <= $x < 10 ) {
print "digit"
}
should do what the user means.
=head1 DESCRIPTION
It is proposed that expressions involving multiple chained comparisons
should be automagically expanded to the equivalent binary conjunction. That is:
0 <= $x < 10
is DWIMmed to:
0 <= $x && $x < 10
Furthermore, it is proposed that any operations, function calls, or subroutine
invocations should only be performed once in such expansions and that such
expansions should short-circuit on failure. That is:
$min < nextval() < $x+$y < length $string
should become:
do {
my $tmp1, $tmp2;
$min < do{$tmp1=nextval} &&
$tmp1 < do{$tmp2=$x+$y} &&
$tmp2 < length $string;
}
=head1 IMPLEMENTATION
As described above
RFC 26 (v1) Named operators versus functions
This and other RFCs are available on the web at http://tmtowtdi.perl.org/rfc/ =head1 TITLE Named operators versus functions =head1 VERSION Maintainer: Johan Vromans <[EMAIL PROTECTED]> Date: 04 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 26 =head1 ABSTRACT Perl distinguishes named operators and functions. For Perl6, this disctinction can be dropped. =head1 DESCRIPTION Named operators, like C, can be called like functions in which case they behave like functions. This has always been so in Perl. Recent versions of Perl allow user-defined functions to be called as operators, using context coercion templates to resolve argument passing. Larry said: "Theoretically, we'd like to make subs run as fast as ops." Since there is no real difference between named operators and functions anymore, they can be treated identically. The difference in terminology can be applied to how it is called instead of how it is defined. So, a I is a user-defined or built-in function called with a parenthesized list of arguments, and a I is a user-defined or built-in function called with its arguments "bare". The latter form is subject to the usual restrictions. Note that this applies to the language aspects. The actual implementation may be different for user-defined and built-in functions. =head1 REFERENCES [i] perldoc perlop
RFC 28 (v1) Perl should stay Perl.
This and other RFCs are available on the web at http://tmtowtdi.perl.org/rfc/ =head1 TITLE Perl should stay Perl. =head1 VERSION Maintainer: Simon Cozens <[EMAIL PROTECTED]> Date: Aug 4 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 28 =head1 ABSTRACT We've got a golden opportunity here to turn Perl into whatever on earth we like. Let's not take it. =head1 DESCRIPTION Perl 6 is our opportunity to give Perl a good spring clean. When you're spring cleaning a house, you throw out the trash and dust down the ornaments, but you don't burn it down and build a shopping mall instead. I think it's reasonably fair to assume that we're all B working on Perl 6 because we like Perl and we want to make it better, not because language design is a fun thing to do of an evening. If that's the case, nobody wins if we bend the Perl language out of all recognition, because it won't be Perl any more. So let's not do this. Let's keep Perl recognisably the language we know and love; let's enhance it, by all means, but let's not turn it into something it isn't. Specifically, we need to watch out for the following ``attractive nuisances''. =over 3 =item Object Orientation Some things just don't need heavy object orientation. B things don't need heavy object orientation, and it's not Perlthink to force programmers into onerous routine they don't need; I'd hate it to get to the stage where I can't write a one-liner because I have to instantiate a class and wibble an object and who the hell knows what else. The CS types may love it, but I'm a programmer and I don't. Let's keep making easy things easy. =item Strong Typing Much the same applies. Strong typing does not equal legitimacy. The CS types may love it, but I'm a programmer and I don't. =item Functional Programming Just because Perl has a C operator, this doesn't make it a functional programming language. Perl has always been squarely procedural, and so things like C and C and other cookery terms are somewhat out of place; they can be far more easily and appropriately implemented as extension modules I. By all means, let's generalise the problem, and make it easier to define your own syntax, but let's not add the entirety of LISP and ML to the core. The CS types may love it, but I'm a programmer and I don't. =item Making Parsing Easier Perl is really hard for a machine to parse. B. If you think it shouldn't be, you're missing something. The syntax and semantics of the Perl language are supposed to fit your mind, not the other way around. It's meant to be far, far more like a human language than a programming language. It's meant to be easy for humans to understand. Yeah, the upshot of this is that, just like a human language, you have to use context to resolve ambiguities in lexing, and the upshot of that is that your tokeniser and parser merge into one. But that's not a big deal as far as implementation is concerned; it's standard natural language processing practice. You're going to have a seriously hard time trying to force Perl into a strict lex/yacc model without completely killing off its attractiveness, and a lex/yacc model doesn't really gain you anything special anyway. The CS types may love it, but I'm a programmer and I don't. =back =head1 IMPLEMENTATION Just don't go raving mad, OK? =head1 REFERENCES
RFC 41 (v2) Request For New Pragma: Implicit
This and other RFCs are available on the web at http://tmtowtdi.perl.org/rfc/ =head1 TITLE Request For New Pragma: Implicit =head1 VERSION Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]> Date: 5 Aug 2000 Version: 2 Mailing List: [EMAIL PROTECTED] Number: 41 =head1 ABSTRACT Perl 6 should add a new pragma called C. =head1 DESCRIPTION I am lazy. I am spoiled by the implicit $_. I like the implicit $_. Implicit $_ good. Ugh. (Conversely, some people abhor the implicit $_ while in a strict programming environment, as it tends to add confusion.) I came to the sysadm / programming world in a long, circuitous route. I never programmed with toggle switches. I've never seen a punch card. My first programming was in Commodore 64 Basic. C64 Basic. No safe-signals there, either. ;) It did have one good thing, though. One very useful thing, for lazy people like me. C could be written like C. It just rolled off the fingers. C<10 ?"Port Perl for the 64!">. Of course, those days have gone. I've seen the light. I'm a *nix head and JAPH. But how I still hate typing out print. Particularly because I do it so much. Oh, sure, I could play games with HERE docs and the ilk, but I'm too lazy. (Like I posted in a response, I wrangled an input filter to allow me to write C pragma that gives new life and meaning to void context constructs. In my case, I want it to print to the default filehandle, (which is also implicit, I might add.) Scoping needs to be tightly controlled, of course. Don't want someone else's void context to show up on your display, now do you? And, of course, it would be defaulted to off. It could continue to ignore constant 0s and 1s. (But those pre-pod embedded comment strings just B to go.) Ideally, I'd like to use it for printing, but I suppose some other lazy person may want to use it for something else. Like, from reading the traffic, to prevent laziness. One of the suggestions was to disallow implicit $_ for functions. That could fit right in with this pragma. It would be on be default, but you could turn it off. =head1 MOTIVATORS Laziness, pure and simple. =head1 IMPLEMENTATION The front-end would have to detect void usage and either arrange to have the results passed to a callback, (in which case, would you know what wantarray() wants to know?) or inject the appropriate term in the optree. In the case of C, the front-end would have to not assume the implicit $_ as an argument. =head2 SUMMARY OF IMPLEMENTATION I've no real concrete ideas on this, sorry. =head2 IMPACT =over 4 =item * Impact on Perl 5. Mutual compatibility between Perl 5 and Perl 6, with the exception of C and the sematics it would add. (Obviously, other changes to the language notwithstanding.) =back =head2 UNKNOWNS =over 4 =item * What about subs? Backticks? Things that return meaningless printable information, like system()? C would put it on the user. After all, he doesn't have to use it. =item * Would C<;> print the contents of $_ to the default filehandle? ;-) =back =head1 REFERENCES Upcoming RFC on module scoping.
RFC 37 (v2) Positional Return Lists Considered Harmf
This and other RFCs are available on the web at http://tmtowtdi.perl.org/rfc/ =head1 TITLE Positional Return Lists Considered Harmful =head1 VERSION Maintainer: Jarkko Hietaniemi <[EMAIL PROTECTED]> Date: 05 Aug 2000 Version: 2 Mailing List: [EMAIL PROTECTED] Number: 37 =head1 ABSTRACT Perl has traditionally returned from various functions long (>2) lists of values. Some traditions are simply bad. =head1 DESCRIPTION Functions like stat() and get*ent() return long lists of mysterious values. The implementation is assumedly easy: just push some values out of C structs into the Perl return stack. Wrong. And once more, wrong. Firstly, who can remember which one of the stat() return values was the atime or which is the 4th return value of localtime()? The perlfunc gmtime/localtime documentation makes this difficulty painfully obvious by having to list the indices alongside the values. Secondly, the current solution is seriously non-extensible. One cannot easily add new return values to the APIs because someone may be expecting an exact number of return values, or someone may be accessing the values by position from the end of the list Obsoleting values (or marking them as non-applicable to the current platform) has to be done by for examples returning undef. =head1 IMPLEMENTATION The solution is simple: return hashes instead of lists. Yes, one still has to know how the fields are named, so the proposed solution is still not perfect. =head2 THE AFFECTED FUNCTIONS caller [1] getgrent getgrnam getgrgid gethostbyaddr gethostbyname gethostent getnetbyaddr getnetbyname getnetent getprotobyname getprotobynumber getprotoent getpwent getpwnam getpwuid getservbyname getservbyport getservent gmtime localtime stat [1] I guess the whole semantics and functionality of caller() is severely up for grabs for Perl6. For the get*() mafia, it is also debatable whether aping the C interface is a good thing and worth preserving as such at all. The preferred interface might be tied hashes. This interface might also more naturally support non-POSIX operating systems with their own native semantics, or POSIX operating systems with extended semantics like higher security user databases. =head1 REFERENCES perlfunc File::stat User::grent User::pwent
RFC 44 (v1) Bring Documentation Closer To Whatever I
This and other RFCs are available on the web at
http://tmtowtdi.perl.org/rfc/
=head1 TITLE
Bring Documentation Closer To Whatever It Documents
=head1 VERSION
Maintainer: Jarkko Hietaniemi <[EMAIL PROTECTED]>
Date: 05 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 44
=head1 ABSTRACT
The current pod has one serious problem: it is very weakly tied to the
whatever it is documenting. A human can make a good guess based on
proximity and content but for more automatic document extraction the
situation is hopeless.
This RFC proposes some syntactical possibilities of binding the
documentation to the things they try to document.
=head1 DESCRIPTION
Both ways of binding the documentation to its main thing and
retrieving the documentation are needed. Below I propose some
possible syntaxes. The proposals are by no means definitive or final,
but the key issue is that the documentation really must be visually
close to its documentee. Any other way is terminally doomed to
failure because then the document and the documentee B drift out
of sync.
=head2 DOCUMENTING A FUNCTION
sub foo "Snarfle the bogogoozer. The first argument is ..." { ... }
=head2 DOCUMENTING THE ARGUMENTS OF A FUNCTION
This example assumes a certain not-yet-existing-or-agreed upon syntax
for "true" named parameters. Pay no attention to details.
sub foo (my $bogogoozer "The victim.", my %options "How to snarfle.")
{ ... }
=head2 DOCUMENTING A LEXICAL VARIABLE
my $literal "How seriously to take the proposal.";
=head2 DOCUMENTING A PACKAGE VARIABLE
$debug_level = 0 "The initial debug level is no debugging, or zero.";
=head2 RETRIEVING THE DOCUMENTATION OF A FUNCTION
print "This is how to snarfle a bogogoozer: ", documentation(\&foo), "\n";
This would retrieve and output the string "Snarfle the bogogoozer.
The first argument is ...".
=head2 RETRIEVING THE DOCUMENTATION OF A VARIABLE
print "This is how literally to take this proposal: ",
documentation(\$literal), "\n";
=head1 IMPLEMENTATION
During parsing the documentation needs to be attached to the thing it
belongs to.
=head2 FURTHER IDEAS
If somebody wants to write documentation in several different
languages (and encodings?) a way to tag a piece of documentation with
attributes would be desirable.
Attributes on the documentation could also be used to differentiate
the documentation to several different classes/types/levels.
=head1 REFERENCES
RFC 42 (v1) Request For New Pragma: Shell
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Request For New Pragma: Shell =head1 VERSION Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]> Date: 5 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 42 =head1 ABSTRACT Perl 6 should add a new pragma called C. =head1 DESCRIPTION The shell that Perl uses for shell interpretation is defined at compile time. Furthermore, it is optimized away when no metacharacters are found within the command string. There are times when one may need (or desire) to change the shell used for interpretation, as well as force shell interpretation, regardless of optimization, for consitency's sake. Perl runs on many platforms. Many of these platforms, either by default, desire, or need, may have multiple command interpreters that Perl may want to interface with by default. (ie, through the use of backticks or system().) Perl is not just a glue language, but a SuperGlue language. I ab^H^Huse Perl to interact with a lot of home-grown command interpreters as either a driver, a hardware controller, or Expect-type engine. It's a lot more DWIMmer when I can operate in that environment, vice the standard OS one. Furthermore, there are times when speed be damned! I need every `` to go through the command interpreter in order to get back consistent results, and I don't want to have to mangle the output string in order to force a metacharacter. It is important, however, that this be lexically scoped. One can't really afford to have some unknown module expect /bin/sh and accidentally send the command to turn on a robot's "Kill Human" mode. =head1 MOTIVATORS Laziness, and perhaps a bit of Hubris. =head1 IMPLEMENTATION This was an easy hack in Perl 5, except for the scoping issue. Ideally, there'd be a -force flag to check, and a method to change the location of the shell, the shell arguments, and perhaps what is defined as a shell metacharacter. =head2 SUMMARY OF IMPLEMENTATION See above. I hacked this for Perl 5 in about two minutes, minus the scoping, which I never could figure out. :-( =head2 IMPACT =over 4 =item * Impact on Perl 5. Mutual compatibility between Perl 5 and Perl 6, with the exception of C and the semantics it would add. (Obviously, other changes to the language notwithstanding.) =back =head2 UNKNOWNS =over 4 =item * What if the interfaced modules returns things that `` and system() don't expect? =back =head1 REFERENCES Upcoming RFC on module scoping.
RFC 45 (v1) || should propagate result context to bo
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE || should propagate result context to both sides. =head1 VERSION Maintainer: Peter Scott <[EMAIL PROTECTED]> Date: 5 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 45 =head1 ABSTRACT Currently the expression lvalue = expr_A || expr_B evaluates C in scalar context, regardless of the type of C, only propagating list or scalar context to C. This proposal is that the context of C should be propagated to C as well. =head1 DESCRIPTION It would be nice to be able to say @a = @b || @c instead of having to resort to @a = @b ? @b : @c The reason that it is not currently possible is that C<@b> (or the list expression in its place) has to be evaluated in scalar context to determine whether to evaluate C<@c>, and that propagating context to C<@b> would require reevaluating it, which might have undesirable side effects (instead of C<@b>, it might be C). =head1 IMPLEMENTATION It seems that it ought to be possible to evaluate something in a list context and test whether there are any entries in the resulting list without having to reevaluate the expression in a scalar context. The work-around with the trinary operator also evaluates C<@b> twice. There is obviously no need to modify the behavior of the C<&&> operator. =head1 REFERENCES L
RFC 15 (v1) Stronger typing through tie.
=head1 TITLE
Stronger typing through tie.
=head1 VERSION
Maintainer: Michael Fowler <[EMAIL PROTECTED]>
Date: 02 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 15
=head1 ABSTRACT
Strong typing of variables can be implemented through the already-existent
tie mechanism.
=head1 DESCRIPTION
Several people have requested strong typing as a feature, but have been shot
down with reasons such as "it's un-Perl-like", with an added "it'll slow
everything down for those who don't want it". However, I think it can be
done in a fairly simple way through the use of the tie mechanism, which
makes the feature optional to those who want an even stricter environment.
Through a pragma or core module one gets various subroutines that produce
tied variables that verify they're only set to allowable values.
Unfortunately, accessing and manipulating tied variables is incredibly slow,
so improving their speed is a large part of making this proposal feasible.
=head1 IMPLEMENTATION
I envision syntax like this:
use typing; # place your fingers on the home row..
integer $foo, $bar, $blah;
string($baz, $qux) = ("bazarific", "quxaroni");
# and even..
my integer $quux = 4;
integer and string are subroutines automatically exported by typing.pm; they
simply tie their arguments to an appropriate class.
The last is a little questionable; it would require some magic on perl's
part to invoke some method or constructor for initializing C<$quux>. A
suggested alternative is something like C, but it
requires some manipulation on perl's part as well.
There is a drawback: exceptions raised ("That's not an integer!" *croak*)
are made at run-time, rather than compile-time (as would be more useful).
As a result you have to test all code paths if you are to use this as any
sort of internal sanity checking; I assume most everyone does this, but it
would be useful for it to be a compile-time check, so that perl -c would
catch all of your errors. This could possibly be accomplished by allowing
arguments to the pragma or variable initialization.
use typing qw(very-strict);
my integer $foo : very-strict = 4;
Which would enforce that you can only assign integer constants to $foo
(which are seen at compile-time), or other similarly declared integers (or
possibly promoted floats, chars, etc. if you wanted to get C-like). This,
then, could allow you to do checking at compile-time.
Which then raises a few more problems (whew): how do you coax user input
(which is an SV) into a value $foo can accept with very-strict on?; what
happens when an external function (say, from a module) is being very-strict,
but is passed arguments from code that doesn't do type checking?
=head1 REFERENCES
perldoc perltie
RFC 29 (v1) unlink() should be left alone
This and other RFCs are available on the web at http://tmtowtdi.perl.org/rfc/ =head1 TITLE unlink() should be left alone =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 04 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 29 =head1 ABSTRACT Some people have suggested that unlink() is too Unix centric, that that it should be renamed to something like delete() or remove(). This should not happen. unlink() should remain unlink(). =head1 DESCRIPTION While on the surface, renaming unlink() may seem like a not-too-bad-idea, in reality it has many bad parts: 1. It confuses experienced Perl, C, and Unix programmers 2. It makes link() and symlink() almost non-sensical 3. It's possible to have more than one link to a file in Unix, meaning unlink() != delete(). 4. It's a useless change. It's not broken. Renaming a function just for the sake of renaming a function, when in reality it works identically to the native C counterpart, does not add value to Perl 6. =head1 IMPLEMENTATION Nothing to be done! For those that are adamant about this, I suggest that they consider writing a module, say "Win32::Synonyms", that could be composed of typeglobs: *delete = \&CORE::unlink; With better referencing in Perl 6 this should be easily possible. However, I think it's RABID (Really A Bad IDea) at best. =head1 REFERENCES RFC 28 (v1) Perl should stay Perl, by Simon Cozens. Unix unlink(2) man page
RFC 10 (v1) Filehandles should use C<*> as a type pr
=head1 TITLE
Filehandles should use C<*> as a type prefix if typeglobs are eliminated.
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 2 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 10
=head1 ABSTRACT
The lack of a type-defining punctuation character prefix for filehandles
makes them second-class variables in Perl. If typeglobs are eliminated in
Perl 6, the C<*> character would become available as a type prefix
character and could be used for filehandles.
=head1 DESCRIPTION
To pass filehandles around one either has to use a typeglob (C)
or put them in a scalar (C or the 5.6 C), at which point you can't tell that they're filehandles without the
right context.
There have been serious proposals to eliminate typeglobs in Perl 6. If
they get axed, the C<*> character could be reused for another datatype and
the filehandle is fortuitously closely related.
The mental jump is fairly small, since most people other than module
developers only ever saw C<*> used for filehandles anyway:
local *FH;
open (FH, ...);
This proposal would change that to
open (my *fh, ...);
=head1 IMPLEMENTATION
Backwards compatibility takes a hit unless the current filehandle syntax is
grandfathered in; I am not taking a position on whether it should
be. Since it is contingent upon typeglobs being eliminated, it won't break
any existing code that already uses typeglobs that won't be broken anyway.
Use of Cs will now look like
while (<*fh>) { ...
which means that the use of the angle operator for globbing also has to
go. As if an excuse were needed.
This proposal also applies to directory handles.
=head1 REFERENCES
L
RFC 9 (v1) Highlander Variable Types
=head1 TITLE
Highlander Variable Types
=head1 VERSION
Maintainer: Andy Wardley <[EMAIL PROTECTED]>
Date: 01 Aug 2000
Version: 1.0
Mailing List: [EMAIL PROTECTED]
Number: 9
=head1 ABSTRACT
Perl5 supports three distinct variable types for any given variable
name corresponding to a scalar (C<$var>), array (C<@var>) and hash
(C<%var>). This RFC proposes that only one type of variable should be
defined for any given name. Where an array or hash is defined
(C<@var> or C<%var>), the equivalent scalar value (C<$var>) would be
an implicit reference to that array or hash array. This would permit
the rationalisation and simplification of the syntax required to
access individual elements or slices of arrays and hash arrays, while
remaining backwardly compatible with Perl5 syntax. The only
semantic difference would be that scripts could no longer rely on
C<$var>, C<%var> and C<@var> referencing different variables.
=head1 DESCRIPTION
Perl5 supports three distinct variable types for any given variable
name corresponding to a scalar (C<$foo>), array (C<@foo>) and hash
(C<%foo>). Each of these may be defined and exists independantly of
the others (NOTE: sub-routines, formats and I/O handles are outside
the scope of this document).
$foo = 'Hello World';
@foo = ( 'Hello', 'World' );
%foo = ( 'Hello' => 'World' );
When accessing variables, and in particular, elements or slices of
lists or hash arrays, the I prefix is used to denote
the multiplicity of the returned value(s); C<$> = 'the', C<@> =
'these'. Although it can be argued that this is logical and
consistent (it is), it can also cause confusion because the prefix is
used to denote what is returned, rather than indicating the variable
from which the value(s) are retrieved. For example:
$foo[2]; # third element of @foo, no relation to $foo
@foo{'bar', 'baz'};# slice of %foo, no relation to @foo
In effect, it is the brackets C<[]> that associate the variable name
with the list type C<@foo> and the braces C<{}> that imply the hash
type C<%foo>.
This RFC proposes that only one type of variable should be defined for
any given name. Where an array or hash is defined, the scalar value
of the same name would implicitly contain a reference to that array
or hash. Thus there can be no confusion as to which of the variables
is being accessed because "there can be only one".
@bar = ( 3, 5, 7 );# $bar is implicitly \@bar
$bar = [ 3, 5, 7 ];# same as above
$bar[2]; # third element of @bar, value 7
$bar->[2]; # same as above
%baz = ( a => 11 );# $baz is implicitly \%baz
$baz = { a => 11 };# identical to above
$baz{ a }; # 'a' entry of %baz, value 11
$baz->{ a }; # same as above
The '->' would become redundant (but optional for backwards
compatability), with an implicit dereference associated with every
pair of braces or brackets. In Perl 5, there is an implied '->'
between every pair of adjacent braces or brackets but not the first,
e.g.
$wiz->[$x][$y][$z]=== $wiz->[$x]->[$y]->[$z]
$waz->{$x}{$y}{$z}=== $waz->{$x}->{$y}->{$z}
Under this proposal, the rule would apply to I cases and the
above examples could be written as:
$wiz[$x][$y][$z]
$waz{$x}{$y}{$z}
Array slices could be specified as either of the following:
$bar[0..2];
@bar[0..2];
Similarly for hash slices:
$baz{'a'..'c'};
%baz{'a'..'c'};# for consistency (not sure about this)
@baz{'a'..'c'};# for backwards compatability
In effect, all arrays and hashes are stored in C<$var> as references to
the same, with C<@bar> and C<%baz> being synonymous for the existing
C<@$bar> and C<%$baz> constructs.
=head1 IMPLEMENTATION
Everything depends on how the internals are reworked.
=head1 ISSUES
Sub-routines would not be affected by these changes, continuing to be
referenced as C<&foo()> or C.
Existing scripts can be automatically converted to preserve multiple
variable semantics, e.g.
$foo -> $foo
%foo -> $foo__hash
@foo -> $foo__list
Internal multi-type variables would need renaming, e.g. @INC/%INC
This RFC could do with a better title.
=head1 REFERENCES
None yet.
RFC 52 (v1) List context return from filesystem func
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
List context return from filesystem functions
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 6 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 52
=head1 ABSTRACT
C, C, and C return the I of successfully
affected files. I suggest that in a list context, they return the I
of the I affected files. Add C to that list as
well, since although it currently only takes one directory name as input,
there is no reason it shouldn't take a list.
=head1 DESCRIPTION
In a scalar context, the result should remain the same as it is now. It is
very tempting to make the list context return be the I
altered files, which is far more intuitive given the scalar context
behavior; but that is almost certainly not the list the user will be
interested in and they'd just end up doing the C suggested in the
docs (Camel III) anyway, which calls the filesystem function once for each
file.
=head2 Hash Context
When the result is assigned to a hash, the list returned could be the names
of the unsuccessfully modified files and their corresponding C<$!> errors.
=head1 IMPLEMENTATION
Examples of use:
# Current behavior: scalar context
chmod 755, grep -d, glob '*' or die "Couldn't chmod dirs"
# List context behavior
warn "Unable to modify $_" for chown $uid, $gid, @files;
# Hash context behavior
%error = rmdir grep -d, glob '*';
warn "Couldn't remove $_: $error{$_}" for keys %error;
It would be nice to include C in this list as well, but there
appears to be no way of doing that without radically changing its
interface, or forcing the I argument to be included, or interpreting
an initial argument that looks like a I to be one. None of those appeal.
=head1 REFERENCES
L
Camel III function list (the entry for C is different from the one
in perl-current at the moment).
RFC 49 (v1) Objects should have builtin string SCALA
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Objects should have builtin string SCALAR method =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 06 Aug 2000 Version: 1 Status: developing Mailing List: [EMAIL PROTECTED] Number: 49 =head1 ABSTRACT Currently, $ single-whatzitz types in Perl can hold several different things. One of the things that these are commonly used to hold are objects, such as: $q = new CGI; $r = Apache->request; Unfortunately, there is no easy way to tell these are actually objects without lots of annoying ref checks throughout your code. So if you say: print "$q"; This prints out something like this: CGI=HASH(0x80ba4e8) Which isn't very useful. This RFC attempts to fix this. =head1 DESCRIPTION Currently, there is no way to easily distinguish between these two syntaxes: $scalar = date; # scalar ctime date, same as localtime() $object = date; # date object with accessor functions As such, there is no easy way to have the C function return both - it must decide what to return within the general scalar context. Damian's excellent RFC 21 on C addresses several specific cases, several have suggested alternate syntaxes, such as: my Date $object = date; # return object of class 'Date' my tm $object = date; # return object of struct 'tm' However, this doesn't solve the problem, since printing out either of these in a scalar context still results in "garbage". I suggest that objects provide a default method called C that determines what they produce in a scalar context. When stringified, an object would automatically call its C function and return the correct value. For example, RFC 48 describes a new C interface. It could produce a date object always: $date = date; However, when you went to do anything with it in a stringifying context, it would call the appropriate method: print "$date"; # calls $date->SCALAR, which in this case would # print out a ctime formatted date string This gives us several other really neat side effects. First, we can now return a list of objects and have them act the same as a "regular old list": (@objects) = Class->new; Since, in a stringifying context, each of these objects would call their C methods: print "@objects"; # calls $objects[0]->SCALAR, $objects[1]->SCALAR, # and so on for the whole array, thus making it # look like a plain old list As such, we no longer have to distinguish between objects and "true" scalars. Objects are automatically converted when appropriate. =head1 IMPLEMENTATION All core objects should be modified to include a C function. This function may just be a typeglob pointing to another function, or it may be an actual separate function. A line must be drawn for what counts as a "scalar" or "stringifying" context. This shouldn't be a difficult line to draw, but it must be made clear. I chose C as the name of the function because it seemed the most obvious. It also leaves us room to add a C, C, and so forth (although I don't see how or why these would be added). I thought of several other alternatives, including C, C, C, and C. One of these (or something else) might be more appropriate. =head1 REFERENCES RFC 21: Replace C with a generic C function A couple other people (sorry, can't find the emails). This is an IOU for "your name here" in version 2. ;-)
RFC 50 (v1) BiDirectional Support in PERL
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE BiDirectional Support in PERL =head1 VERSION Maintainer: Roman M. Parparov <[EMAIL PROTECTED]> Date: 06 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 50 =head1 ABSTRACT This paper proposes an RFC regarding the B input and output support which would allow easier correct treatment for the languages with RTL (Right-To-Left) writing direction, such as Hebrew, Arabic and others. Such a support would mean a breakthrough in preparing all kinds of applications of users that need bidirectional text. =head1 DESCRIPTION =head2 Concepts of Bidirectional Support The aspects of RTL support in general were outlined in the I[1]. Since the bidirectional input issue is much more complicated than output and requires deep support of other applications than PERL, this document will only deal with the string output and string processing, just like the ECMA do. We will assume that the BDL data is always being read just as it is being read from the regular input buffer. =head2 Output of BDL strings in Perl6: Based on the above, PERL 6 should implement an output routine like this: rtlprint FILEHANDLE,LIST,REPRESENTATION,DIRECTION rtlprint FILEHANDLE,LIST,REPRESENTATION FILEHANDLE is the FILEHANDLE of print. LIST is the LIST of 'print'. REPRESENTATION should be a value represented by a scalar - either 'v' for VISUAL, or 'l' for LOGICAL. LIST is a LIST of 'print'. DIRECTION is either 'rtl' or 'ltr' and is optional, 'rtl' being the default value. OR enhance the existing print operator to print FILEHANDLE, LIST, REPRESENTATION,DIRECTION In this case the default value of REPRESENTATION is LOGICAL. The output formats, if left, should be supported by RTL output. Other outputting statements like "die", do not have to support RTL output. =head2 Data processing of BDL strings in Perl6: B for the RTL strings is required. The 'r' char after the last slash would mean an RTL string. Routine B should be able to return subroutines cut from the right side from the RTL strings, including mixed texts. =head1 IMPLEMENTATION The implementation of that function should be a thorough coding of the BiDirectional Languages ECMA spec mentioned above. A mixed combination of RTL and LTR languages is allowed in a text, and the rules of punctuation are not often obeyed, but we should just stick to the ECMA standard. =head1 REFERENCES [1] Handling of the Bi-Directional Texts - ECMA TR/53 - F<ftp://ftp.ecma.ch/ecma-tr/tr-053.pdf> F<ftp://ftp.ecma.ch/ecma-tr/tr-053.psc>
RFC 17 (v2) Organization and Rationalization of Perl
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Organization and Rationalization of Perl State Variables
=head1 VERSION
Maintainer: Steve Simmons <[EMAIL PROTECTED]>
Date: 3 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 17
CVSID: $Id: RFC17.pod,v 1.3 2000/08/07 18:32:04 scs Exp $
=head1 ABSTRACT
Perl currently contains a large number of state and status variables
with names that resemble line noise (henceforth called C<$[linenoise]>
variables).
Some of these are (or should be) deprecated, and the naming methods for
the rest are obscure. Since we are (potentially) adding, removing, and
changing the functionality of these variables with Perl6, we should seize the
opportunity to rationalize the names and organization of these variables
as well. These variables need to be made available with mnemonic names,
categorized by module, be capable of introspective use, and proper
preparation made for deprecation and translation.
=head1 DESCRIPTION
C allows for the runtime examination and setting of a number of
variables. These existing C<$[linenoise]> variables are horrible names and
need cleanup, re-organization, and syntactic sugar. Different variables
have different problems, usually one or more of the following:
=over
=item *
unused (as far as we know)
=item *
useless, but still appear in older programs
=item *
duplicated by other features
=item *
standing in the way of advance because of backwards compatibility
=back
In the pre-RFC discussion of this issue, it was also pointed out
that these variables are hard to deprecate without nagging the crap
out of users running the programs. The proposed solution was
broadly applicable, and has been spun off into RFC 3.
The use of the C module is an attempt to solve the anti-mnemonic
features of these variables. A better solution is to do it right in
the first place, with a number of attendant wins:
=over
=item *
no need for Yet Another Module to be loaded
=item *
promotes code readability
=item *
probably promotes core Perl maintainability
=item *
grouping sets of variables together by function gives
the code writer strong hints as to variables that might
affect each other
=item *
should we move formats (or any similar current core functionality)
to a loadable module, this neatly encapsulates all the data with
a single referenced name
=item *
solves problems with C<$[linenoise]> variable proliferation
=item *
potentially promotes introspection - see below.
=back
In addition, many features which are now (re)set by other calls should
set appropriate state variables as well. Thus a C script which
contains:
use strict foo;
might set a var C<$PERL_STRICT{foo}>, and so forth (this is probably
a poor example).
Credit where it is due: the idea of putting related values together into
an appropriately tagged hash is shamelessly ripped off from common C usage.
=head3 Caveat - Global State Variables Are Dangerous
Having the setting of simple variables modify the function of a
broad set of things is an inherently dangerous and inelegant way of
doing things. Mark-Jason Dominus <[EMAIL PROTECTED]> has proposed that
they simply be removed whenever possible. I tend to agree with his
arguement, and join in urging that the problems he addresses in message
C<[EMAIL PROTECTED]> be addressed by the core teams
working in the areas that use such variables. The thread started my
Mark-Jason in C has a good discussion of the issues.
Notwithstanding, should the core team continue to allow global
variables for some purposes, the names and categorization should
be improved.
=head2 Advantages and Non-Loses
=head3 Clean Backwards Compatibility
To promote backward compatibility, one could write a C
module which would alias the old names to the new ones. That Would Be
Wrong, but someone will probably do it - so it may as well be us.
Obviously we cannot provide backwards compatibility for a variable
whose meaning has changed or which has vanished, but most of the
rest can be captured cleanly.
=head3 Promoting Removable Core Modules
It has been strongly proposed that `core C' be broken down internally
into a number of modules such that one could build smaller or larger
custom perls. This feature would ease that work, and possibly set a
standard for how well-behaved non-core modules should implement such
things.
=head3 Provide Possible Guidelines To Core-able Modules
The discussion of removable core modules has strongly implied (sometimes
explicitly stated) that sites could take modules which are not currently
in the core and move them there. Having a standard which those modules
could follow for variable setting and exposure would be a major win.
=head2 Disadvantages
=head3 Backwards Compatibility
Existing C code which makes use of C<$[linenoise]> variables
which had not changed meaning in C will fail if (as propose
RFC 48 (v2) Objects should have builtin stringifying
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Objects should have builtin stringifying STRING method =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 06 Aug 2000 Version: 2 Status: Developing Mailing List: [EMAIL PROTECTED] Number: 48 =head1 ABSTRACT Currently, $ single-whatzitz types in Perl can hold several different things. One of the things that these are commonly used to hold are objects, such as: $q = new CGI; $r = Apache->request; Unfortunately, there is no easy way to tell these are actually objects without lots of annoying ref checks throughout your code. So if you say: print "$q"; This prints out something like this: CGI=HASH(0x80ba4e8) Which isn't very useful. This RFC attempts to fix this by providing builtin special method C which is automatically called when an object is "stringified". =head1 DESCRIPTION Currently, there is no way to easily distinguish between these two syntaxes: $scalar = date; # scalar ctime date, same as localtime() $object = date; # date object with accessor functions As such, there is no easy way to have the C function return both - it must decide what to return within the general scalar context. Damian's excellent RFC 21 on C addresses several specific cases, several have suggested alternate syntaxes, such as: my Date $object = date; # return object of class 'Date' my tm $object = date; # return object of struct 'tm' However, this doesn't solve the problem, since printing out either of these in a scalar context still results in "garbage". I suggest that objects provide a default method called C that determines what they produce in a string context. When stringified, an object would automatically call its C function and return the correct value. For example, RFC 48 describes a new C interface. In a scalar context, it could produce a date object always: $date = date; However, when you went to do anything with it in a string context, it would call the appropriate method: print "$date"; # calls $date->STRING, which in this case would # print out a ctime formatted date string The call to C<$object->STRING> would be a decision made by Perl, similar to the way that C works. The object simply has to provide the method; Perl does the rest. This gives us several other really neat side effects. First, we can now return a list of objects and have them act the same as a "regular old list": (@objects) = Class->new; Since, in a stringifying context, each of these objects would call their C methods: print "@objects"; # calls $objects[0]->STRING, $objects[1]->STRING, # and so on for the whole array, thus making it # look like a plain old list As such, we no longer have to distinguish between objects and "true" scalars. Objects are automatically converted when appropriate. =head1 IMPLEMENTATION All core objects should be modified to include a C function. This function may just be a typeglob pointing to another function, or it may be an actual separate function. Hooks will have to be put in Perl's string context so that if something is an object, then that object's C method is called automatically. If no C method is defined, then it should simply return undef (instead of printing out the ref/class info). If people want to see the ref info, they can still type: print $object; since this is not a string context. However, print "$object"; should always return something that's worth seeing, even if that's nothing. =head1 REFERENCES RFC 21: Replace wantarray with a generic want function RFC 48: Replace localtime() and gmtime() with date() Lots of people on perl6-language for great input, thanks!
RFC 62 (v1) Wildcards for multiple module imports
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Wildcards for multiple module imports =head1 VERSION Maintainer: Peter Bevan <[EMAIL PROTECTED]> Date: 8 August 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 62 =head1 ABSTRACT It occurs that being able to include modules via wildcards for entire packages would be a desirable feature. Just as in Java, related packages could then be loaded implicitley without the need for specifying each one in turn. The LWP and Net packages, are a good example. =head2 DESCRIPTION A directory in the perl library is intended to encapsulate modules which have relevance to each other (again the Net package is a good example). Given that this is the case (and given extensive expirience) it is apparent that there are many situations in which onw would wish to load the entire group. As things stand this is not a possibility (without reading the dir stuctures and loading each file dynamicly - which isn't a great idea). As a side point this may push module developers into even better co-operative working enviroments (i.e. they will need to work much more closely together in order to tie up their respective modules) =head2 IMPLEMENTATION The option to load modules thus: use Foo::* [The '*' character isn't very pleasant, any sugestions??] or use Foo::Bar::* [An alternate Foo::, has been sugested] etc Also, having thought about it, it occurs that the ability to opt-out of such a scheme is desirable. This could be acheived by eigther setting some kind of global identifier within the module to signal it's "community-mindedness" or possibly a new naming convention (.pm for modules which have opted-out and .pmc for instance, for those which have not). It may even be possible to set a flag of somekind in the module packlist. I guess thats up to the internals developers to decide... =head2 REFERENCES Any java class package... perldoc perlmod
RFC 64 (v1) New pragma 'scope' to change Perl's defa
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
New pragma 'scope' to change Perl's default scoping
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 07 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 64
=head1 ABSTRACT
Historically, Perl has had the default "everything's global" scope. This
means that you must explicitly define every variable with my, our, or
its absolute package to get better scoping. You can 'use strict' to
force this behavior, but this makes easy things harder, and doesn't fix
the actual problem.
Those who don't learn from history are doomed to repeat it. Let's fix
this.
=head1 MOTIVATORS
Tons of Impatience, a good amount of Laziness, and a dash of Hubris
=head1 DESCRIPTION
=head2 Overview
First off, let's clear up what this RFC does NOT do: it does B
change Perl's default scoping. By default, Perl should be scoped
globally, as it always has been and always should continue to be.
Rather, this RFC suggests a pragma that will offer alternative scoping
rules, to make easy things even easier.
In a default Perl script, everything is global. Which means in:
$x = 10;
if (1) {
unless (undef) {
$y = 1 if ($x);
}
}
$x and $y are in the same scope. This is good, but also bad. For one
thing, you can hang yourself real easily if you come from a C background
and expect this to keep stuff private:
$x = 10;
sub square {
($x) = @_;
$x *= $x;
}
$ans = square($x);
print "$x squared is $ans\n"; # "100 squared is 100" ?
Ooops. What happened? Turns out the sub square()'s $x is the same $x as
the one outside. Bad news, you reset the (global) value of $x. Ooops.
RFC 6 addresses this problem, but in the wrong way. In Perl, you can
'use strict' to force you to predeclare all your variables with my or
our (which you can do anyways if you feel like it). So the above code
becomes:
use strict;
my $x = 10;
sub square {
my($x) = @_;
$x *= $x;
}
my $ans = square($x);
print "$x squared is $ans\n";
So, with the addition of C and 3 "little" C's, we've
resolved the ambiguity. Problem is, this is a good amount of work
(especially if you're Lazy *and* Impatient, like I am) for such a stupid
little 5-line script. Plus, it makes the code markedly harder to read.
Setting 'use strict' to the default makes easy things harder - very
UN-Perlish! Eck.
The better solution is to fix the actual *problem* (Perl's scoping), and
provide a method for automatically scoping variables via different
algorithms than Perl's default. As Daniel Chetlin notes in RFC 16
(against strict defaults):
Making strict 'vars' default appears to be an attempt to fix
a hole in the floor by permanently barring access to the room
in which the hole is, rather than just patching the hole.
Let's patch the hole.
=head2 Different Scoping Algorithms
This RFC describes several different types of scoping. They can be used
together, yielding advanced scoping without the mess of C. Each of
these would be specified as:
use scope qw(types);
Where "types" are the types listed below. By default, 'all' is used,
which turns on all scoping rules. As of version 1, there are currently
two proposed types of scopes: C and C.
Note that you can still use an explicit C or C keyword to
override the C pragma. The C pragma only affects variables
that are not explicitly declared.
=head3 subs
The C scoping pragma makes one key change: it automatically scopes
variables within subs as if they were C'ed at the top of the sub.
So, the code:
use scope 'subs';
sub dostuff {
($one, $two, $three) = @_
if ( $two > 5 ) {
$four = 1;
} else {
$five = 2;
while ( $five < 6 ) {
$five++;
}
}
return $four || $five;
}
Would be internally changed to the same thing as if all of C's
variables had been declared with C as the first statement in the
sub. This keeps you from clobbering yourself with:
($three, $four, $five) = readvals;
$six = dostuff($five, $three, $four);
Without the need to declare all those C's all over the place.
The exceptions to the C scoping pragma are BEGIN, END, and any
other special Perl subs that may apply.
=head3 blocks
The C scoping pragma automatically scopes variables to the
innermost B block. The key work here is anonymous. The main
program itself is seen as the outermost block. So, this code:
$x = 10;
{
$x = 5;
}
if ($x == 10) {
$x = 25;
}
print "$x\n";
Would result in "25" being printed out. Here's why:
1. The C<$x = 10> is automatically scoped with its own C.
2. The C<$x = 5> inside the B block is automatically
scoped with its own C.
3. The C<$x = 25> code, however, inside the C statement
is not scoped, since it is not an B block. Since
there is already an C<$x> in the current block, there is
no n
RFC 79 (v1) Code which is both executable and POD.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Code which is both executable and POD.
=head1 VERSION
Maintainer: John Porter <[EMAIL PROTECTED]>
Date: 9 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 79
=head1 ABSTRACT
Allow some executable code to be recognized also as POD.
=head1 DESCRIPTION
As of Perl 5, any chunk of source text is either POD, or executable code.
This RFC proposes that a class of source text be allowed which is both
recognized as POD by any POD processor, and as non-POD by the perl parser.
This allows actual running code to be inserted directly into the documentation
for that code.
=head1 IMPLEMENTATION
How this is implemented depends on whether supporting changes can be made
to the perl parser, to POD processors, or both. Changes to the POD specification
can reasonably be assumed to necessitate changes to both the perl parser and
to POD processors.
=head2 1: Leave perl's POD recognition unchanged; modify POD processors
This could be done by adding a variant of the C<=cut> directive, which
is recognized as a normal C<=cut> by perl, but is passed over by POD
processors. This exploits the fact that perl stops ignoring text at
the C<=cut> directive. The POD processors must be modified to NOT stop
accumulating POD when they see the C<=cut include> directive.
The downside of this approach is that overlaps between pod and code can
only occur in this order ( pod, both, code ). Alternatively, the POD
processors could also I accumulating code on a C<=cut include> directive,
but this would look kludgy.
Example:
=pod
This documents the code.
=cut include
sub foo($\%@)
=cut
{
#code for foo
}
=head2 2: The POD spec is changed to include special directives
This is cleaner, but has farther reaching effects in both
the perl parser and POD processors.
This could be done by adding a special variant of the C<=pod> directive,
such as C<=pod code>.
Example:
=pod
Normal documentation.
=pod code
sub foo($\%@)
=cut
{
#code for foo
}
=pod code
$^W = 1; # enable warnings :-)
=pod
Rest of documentation.
=cut
=head1 REFERENCES
RFC 5: "Multiline Comments for Perl"
RFC 11: "Examples encoded with =also for|begin|end POD commands"
RFC 44: "Bring Documentation Closer To Whatever It Documents"
perlpod manpage for discussion of POD.
=cut
RFC 84 (v1) Replace => (stringifying comma) with =>
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace => (stringifying comma) with => (pair constructor)
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 10 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 84
=head1 ABSTRACT
This RFC proposes the introduction of a new data type -- the I -- and
the co-opting of the => operator to act as a pair constructor. Most existing
uses of => would be preserved.
=head1 DESCRIPTION
It is proposed that a new data structure, to be known as a I, be
added to the language. The => operator would cease to be a
first-argument-stringifying comma operator, and becomes an anonymous pair
constructor (just as [...] and {...} are anonymous list and hash constructors
respectively). The => operator would return a reference to a pair containing
the two operands to =>.
The first component of a pair would be called its C, and the second, it's
C. It is proposed to either extend the semantics of C and
C to allow them to operate of pair references, or else introduce
two new built-ins -- C and C -- to access the components of a pair.
=head2 Pairs and hashes
A hash could be constructed from a list of pair references. In fact a
hash could be thought of (and perhaps implemented!) as a set of pairs.
Thus:
%hash = ( a=>1, b=>2, 'c', 3 );
does what it does in Perl 5, but works slightly differently. The list being
assigned consists of four elements (not six): a pair reference, another pair
reference, a string, and an integer.
When a pair reference is assigned (in)to a hash, the pair's key becomes
the hash entry's key, and the pair's value becomes the entry's value
As the above example indicates, hashes could still be assigned "flat" lists.
=head2 Pairs and arrays
When a pair reference is assigned (in)to an array, it remains a single scalar
(referential) value. So:
@array = ( a=>1, b=>2, 'c', 3 );
assigns four elements (not six) to @array.
=head2 Pairs and subroutines
When a pair reference is used in the argument list of a subroutine with
no parameter list, it is passed as a single scalar value (i.e it remains
a pair reference).
When a pair reference is passed to a subroutine with named parameters, it
binds its value to the parameter of the same name, regardless of the order
in which it is passed.
Thus:
use Data::Dumper;
sub no_params {
print "no_params:\n"
print join "\n", map {ref||"scalar val"} @_;
print Dumper @_;
}
sub params ( $name, $rank, $serial_num) {
print "params:\n"
print join "\n", map {ref||"scalar val"} @_;
print Dumper @_;
}
no_params(serial_num=>1234, name=>'demo', rank=>'RFC');
params(serial_num=>1234, name=>'demo', rank=>'RFC');
prints:
no_params:
PAIR
PAIR
PAIR
$VAR1 = ( 'serial_num' => 1234 );
$VAR2 = ( 'name' => 'demo' );
$VAR3 = ( 'rank' => 'RFC' );
params:
scalar val
scalar val
scalar val
$VAR1 = 'demo';
$VAR2 = 'RFC';
$VAR1 = 1234;
Note that these semantics still support the popular:
sub hash_like_args {
my %args = @_;
# etc.
}
hash_like_args(serial_num=>1234, name=>'demo', rank=>'RFC');
=head2 Pairs and multiway comparisons
Pairs also provide a clean way of implementing multiway comparisons.
It is proposed that when a pair is evaluated in a boolean context, it
would evaluate to the truth value of its key. But when evaluated as the left
operand of a comparison operator, it would evaluate to its value,
I would short-circuit if its key were false.
Thus:
1 < 4 < 7 < 9
would be evaluated:
(((1 < 4) < 7) < 9)
(((true=>4) < 7) < 9) # true because 1 < 4
((true=>7) < 9) # true because 4 < 7
(true=>9) # true because 7 < 9
1 # boolean context evals to truth of key
On the other hand:
1 < 4 < 7 < 3 < 9
would be evaluated:
1 < 4) < 7) < 3) < 9)
true=>4) < 7) < 3) < 9) # true because 1 < 4
(((true=>7) < 3) < 9) # true because 4 < 7
((''=>3) < 9) # '' (false) because !(7 < 3)
'' # short circuits to false
=head1 REFERENCES
Forthcoming Conway RFC on subroutine parameter lists
(including named parameters)
RFC 25: Operators: Multiway comparisons
RFC 85 (v1) All perl generated errors should have a
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE All perl generated errors should have a unique identifier =head1 VERSION Maintainer: Chaim Frenkel <[EMAIL PROTECTED]> Date: 9 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 85 All perl generated errors should have a unique identity. So that changes in the text should not cause breakage in code. =head1 DESCRIPTION Currently many programs handle error returns by examining the text of the error returned in $@. This makes changes in the text of the error message, an issue for the backwards compatibility police. An added benefit, depending upon the actual method of identifing errors selected could be a classification scheme for errors. =head1 IMPLEMENTATION Each unique identifier once assigned as part of a stable release of perl will be guarenteed never to be changed, or if the error text is removed, never to be reused. =head2 Encodings I have listed some possiblities. But none of these are ideal. =head3 A unique number Each error message will be assigned a unique number. The number could be made accessible via the $@ in a numeric context. =over 4 =item As an integer This would be simple and direct =item As a floating point number The integer part would be the actual identifier. The fractional part could encode some classification scheme. =back =head3 Unique String Each error message will have a unique string assigned. The unique string could be accessible as $@->unique_id =head3 Prefixes for all error strings (Shades of Big Blue) Each error message will have a unique string that will be part of the text. For those of you who have ever read through the IBM Codes and Errors manual this will look familiar. For example FIL0001W unable to close filehandle %s properly PAR0003F Can't find label %s =head2 Classification Schemes To be defined. Suggestions welcome. =head1 REFERENCES
RFC 82 (v1) Make operators behave consistently in a
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Make operators behave consistently in a list context =head1 VERSION Maintainer: Jeremy Howard <[EMAIL PROTECTED]> Date: 10 August 2000 Version: 1.00 Mailing List: [EMAIL PROTECTED] Number: 82 =head1 ABSTRACT It is proposed that in a list context, operators are applied component-wise to their arguments. Furthermore, it is proposed that this behaviour be extended to functions that do not provide a specific list context. =head1 DESCRIPTION Currently, operators applied to lists in a list context behave counter-intuitively: @b = (1,2,3); @c = (2,4,6); @d = @b * @c; # Returns (9) == scalar @b * scalar @c This RFC proposes that operators in a list context should be applied component-wise to the elements of their arguments: @d = @b * @c; # Returns (2,8,18) If the lists are not of equal length, the shorter lists should be treated as if they were padded with undefs at the right-hand end. However, this implicit padding should not cause these elements in the shorter lists to auto-vivify. Functions that do not return a list should be treated in the same way: @e = (-1,1,-3); @f = abs(@e); # Returns (1,1,3) =head1 IMPLEMENTATION These operators and functions should be evaluated lazily. For instance: @b = (1,2,3); @c = (2,4,6); @d = (-2,-4,-6); $sum = reduce ^_+^_, @b * @c + @d; should be evaluated as if it read: $sum = 0; $sum += $b[$_] * $c[$_] + $d[_] for (0..$#b-1)); That is, no temporary list is created, and only one loop is required. The proposal to handle functions is tricky, since there is currently no obvious way to see whether a function is going to return a list. Either we need some kind of more advanced prototyping (or other way of creating a signature), or we need to manually change functions provided with Perl to check for list context and Do The Right Thing. =head1 REFERENCES The Mathematica Navigator, Heikki Ruskeepää, Academic Press, ISBN 0-12-603640-3, p383. Expression Templates (C++ Implementation): http://extreme.indiana.edu/~tveldhui/papers/techniques/techniques01.html#l32 Implementation in Perl Data Language: http://pdl.perl.org
RFC 83 (v1) Make constants look like variables
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Make constants look like variables
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 10 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 83
=head1 ABSTRACT
This RFC proposes that the current constant.pm module removed, and
replaced with a syntax allowing any variable to be marked as constant.
=head1 DESCRIPTION
Currently, constants are created in Perl using the constant.pm module:
use constant PI => 3.1415926;
which creates an inlined subroutine:
sub PI () {3.1415926;}
This method of creating constants has three serious drawbacks:
=over 8
=item Can not be interpolated in strings
Whereas variables can be interpolated into strings (e.g. "PI is $Pi"),
subroutines can not be. This makes using constants inconvenient, since
string concatenation must be used.
=item Inconsistant syntax
The sudden appearance of barewords can be quite unsettling to new users.
After becoming told that 'arrays are @name, scalars are $name, ...', the
rule suddenly stops working just because the programmer wants the value to
stay constant.
=item Redundant warnings
In persistant Perl environments such as mod_perl, inlined subroutines
often created the redundant warning 'Constant subroutine PI redefined'.
This has been a frequent source of confusion amongst new mod_perl users.
=back
It is proposed that a new syntax for declaring constants be introduced:
my constant $PI = 3.1415926;
my constant @FIB = (1,1,2,3,5,8,13,21);
my constant %ENG_ERRORS = (E_UNDEF=>'undefined', E_FAILED=>'failed');
Constants can be lexically or globally scoped (or any other new scoping
level yet to be defined).
=head1 IMPLEMENTATION
Constants should have the same behaviour as the do now. They should be
inlined, and constant expressions should be calculated at compile time.
=head1 REFERENCES
perldoc constant; perldoc perlsub (for constant subroutines)
RFC 8 (v2) The AUTOLOAD subroutine should be able t
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
The AUTOLOAD subroutine should be able to decline a request
=head1 VERSION
Maintainer: Leon Brocard <[EMAIL PROTECTED]>
Date: 10 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 8
=head1 ABSTRACT
In Perl 5, the first AUTOLOAD subroutine found in an object's hierarchy
is used and any other AUTOLOAD subroutines higher up are ignored. I
propose that in Perl 6 we allow AUTOLOAD subroutines to decline a
request, which allows other AUTOLOADs to cope with it.
=head1 DESCRIPTION
AUTOLOAD is a very useful and handy way to handle cool and exciting
things, but as has been pointed out many times before, only one
AUTOLOAD can be called in the object's hierarchy, even if multiple ones
exist. This is due to the fact that AUTOLOAD subroutines must do
something - they can not currently decline a request. I propose one of
the methods which has previously been discussed on p5p.
Instead of calling the right thing or actually doing the right thing,
AUTOLOAD subroutines should return a coderef which will be run as if
it were the method called. If an AUTOLOAD subroutine does not wish to
cope with a method call, it should return undef. Perl would then walk
the OO hierarchy and find the next AUTOLOAD to call, eventually failing
with an error if no AUTOLOAD method is found which will accept the
call.
=head2 EXAMPLE
The following Perl 5 code (an extension of the AUTOLOAD example in the
perlsub manpage):
sub AUTOLOAD {
my $program = $AUTOLOAD;
my @args = @_;
$program =~ s/.*:://;
if ($program =~ /^[aeiou]/) {
system($program, @args);
}
}
... would be rendered as the following in Perl 6:
sub AUTOLOAD {
my $program = $AUTOLOAD;
my @args = @_;
$program =~ s/.*:://;
if ($program =~ /^[aeiou]/) {
return sub { system($program, @args) }
} else {
return undef;
}
}
=head2 $AUTOLOAD
While we're at it, it *may* be a good idea to remove the global
$AUTOLOAD variable and instead pass it as the first parameter of the
AUTOLOAD subroutine call. For: general global drought, the fact that
perlsub's argument "because, er, well, just because, that's why..." is
a bit weak. Against: makes AUTOLOAD more complicated, breaking the
"subroutine parameters end up as @_" paradigm (apparently).
=head2 UNIVERSAL->can
This proposal has the added bonus that the UNIVERSAL->can method (or
whatever replaces it) will now work with AUTOLOAD-ed methods, whereas
in Perl 5 it used to fail.
=head1 IMPLEMENTATION
This strikes me as being a fairly easy thing to do, but then again
internals ain't my thing, baby.
=head1 REFERENCES
Mike Guy's "AUTOLOADREF" idea on p5p:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-03/msg01317.html
Ilya Zakharevich "sub autoload" idea on p5p:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-01/msg01381.html
RFC 76 (v1) Builtin: reduce
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtin: reduce
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 76
=head1 ABSTRACT
This RFC proposes a builtin C function, modelled after Graham Barr's
C subroutine from builtin.pm
=head1 DESCRIPTION
A new builtin -- C -- is proposed.
This function would take an block, subroutine reference, or curried function
(hereafter referred to as I),
and call it repeatedly to reduce the remaining arguments
(hereafter, referred to as C).
If the reduction subroutine has a prototype, that prototype
determines how many items are reduced at a time. If the reduction subroutine
is a block or has no prototype, two items are reduced each time.
The first call to the reduction subroutine will be passed the first N
elements of the list, and subsequent calls will be passed the result of
the previous call and the next N-1 elements in the list, until no more
elements remain in the list. If fewer than N-1 elements remain on the
final call, all the remaining elemetns are passed.
If the original list has no elements, C immediately returns C.
If the original list has a single element, that element is immediately returned
(without every calling the reduction subroutine).
Otherwise, the result of the final reduction call is the result returned
by C.
If the reduction subroutine is ever terminated by a call to C,
the enclosing C immediately returns the last reduction value
(i.e. C on the first reduction call, $_[0] otherwise)
=head1 EXAMPLES
Summation:
$sum = reduce {$_[0]+$_[1]} 0, @numbers;
$sum = reduce sub{$_[0]+$_[1]}, 0, @numbers;
$sum = reduce ^_+^_,0, @numbers;
Note that the first element of the list -- zero in this case, 1 in the next
example -- represents the default value if the list is empty.
Production:
$prod = reduce {$_[0]*$_[1]} 1, @numbers;
$prod = reduce sub{$_[0]*$_[1]}, 1, @numbers;
$prod = reduce ^_*^_,1, @numbers;
Minimization:
$min = reduce ^x <= ^y ? ^x : ^y, @numbers
$min = reduce ^x le ^y ? ^x : ^y, @strings
Minimization to zero:
$min = reduce any(^x,^y)<0 && last || ^x<^y && ^x || ^y, @numbers
Collection:
@triples = @{ reduce sub($;$$$){ [@{shift},[@_] }, [], @singles };
Separation:
$sorted = reduce { push @{$_[0][$_[1]%2]}, $_[1]; $_[0] }
[[],[]],
@numbers;
=head1 IMPLEMENTATION
Extend Graham's builtin, I'd imagine.
=head1 REFERENCES
builtin.pm
RFC 77 (v1) Suggested isa() operator.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Suggested isa() operator.
=head1 VERSION
Maintainer: James Mastros <[EMAIL PROTECTED]>
Date: 08 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 77
=head1 ABSTRACT
Currently, there is no way to determine if a scalar holds something that
could validly form a number/Boolean/etc. This RFC seeks to remedy that.
=head1 DESCRIPTION
The suggested semantics of the isa operator are as follows:
=over 4
=item $result = isa($obj, $type);
TRUE VALUES:
$result = "blessed" if $obj is blessed into the package $type.
$result = "inherits(n)" if $obj is blessed into a package that ISA $type in the Nth
degree.
$result = "is a" if $obj currently has a $type value associated with it.
$result = "can be a" if $obj could be promoted to a $type value.
$result = "tied to a" if $obj is tied to (something which inherits from) $type.
FALSE VALUES:
$result = 0 if $obj is not a $type, but $type is a known package or basic type.
$result = undef if $type is not a known package or basic type.
in all cases, if $type is a blessed ref, it should be taken as if ref($type)
had been specified. An unholy ref is invalid for $type.
=back
This is incompatible with UNIVERSAL::isa() in one case: if $obj is a
string containing the name of a package, the current C will do what the proposed C would do.
This, fortunately, would not be automatically convertible. Therefore, it
might
be better to have the existing semantics apply to C when
$obj holds the name of an existing package. Unfortunately, this means that
you cannot apply isa() to arbitrary strings in absolute safety. FIXME.
=over 4
=item @result = isa($obj, $type);
@result is the lineage of $obj that leads to $type. More exactly, it
is a list such that C. (Hmm, perhaps things like that are a good argument for why
isa should treat $obj=a package name specialy.) Also, the list will always
either be empty (if C is false), or will end in
(the cannonical form, if there is some noncannonical form of package names
or basic types).
=item $result = isa($obj);
$result is the basic type of $obj -- "INTEGER", "NUMBER", "STRING", "REF",
"FILEHANDLE", etc. This is it's most specific IS_xOK() (or similar) type
(INTEGER winning over NUMBER, which wins over STRING, FILEHANDLE winning
over REF, if they end up being different basic types). Note that this
doesn't dereference $obj or give the type it is blessed into; ref() is for
that. (If you want to know the basic type of the object that it points to,
even if it is blessed, see the next form.)
=item @result = isa($obj);
This will follow the chain of refs, giving a list of the packages, etc, of
each, as well as going into lists and hashes. For example:
my $foo = [14, "21"];
my $bar = bless (\$foo, "Example::Package1");
my $baz = bless (\$bar, "Example::Package2");
print Data::Dumper \(isa($baz));
Will print (assuming I got the parentheses right on that last line):
("Example::Package2", "Example::Pacakge1", "LIST", ["INTEGER", "STRING"])
Note that the last element is a ref to the list that doing a list of
scalar(isa($thingies)) on the thingy that has it's type mentioned in
the -2th element. This has the possibility of producing very deep (even
infinitely deep/self-referencing) lists, and should possibly be limited to
the return of the scalar form, or omitted entirely. However, completely
eliminating it would mean that you couldn't find the types of a list of
items by doing isa(\@list). FIXME.
Also, I'm not sure what to do about tied thingies, since things can be
tied, blessed, and have subvalues all at the same time. FIXME.
This would have to stop somewhere with recursive and infinite (including
non-terminating ties, infinite, and semi-finite lists/hashes) structures.
FIXME.
Note also that this has the list at the end returning the current basic type
instead of the most specific possible basic type. FIXME.
=back
=head1 IMPLEMENTATION
Hmm, it's natively (and naïveté) recursive.
=head1 UNRESOLVED ISSUES
C.
=head1 REFERENCES
L for UNIVERSAL::isa compatibility
L
RFC 78 (v1) Improved Module Versioning And Searching
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Improved Module Versioning And Searching =head1 VERSION Maintainer: Steve Simmons <[EMAIL PROTECTED]> Date: 8 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 78 CVSID: $Id: modules.pod,v 0.3 2000/08/09 04:01:14 scs Exp $ =head1 ABSTRACT Modern production systems may have many versions of different modules in use simultaneously. Workarounds are possible, but they lead to a vast spaghetti of fragile installation webs. This proposal will attempt to redefine module versioning and its handling in a way that is fully upward compatible but solves the current problems. An up-to-the-instant version of this RFC will be posted as HTML at C<http://www.nnaf.net/~scs/Perl6/RFCxx.html> as soon as I know the RFC number. =head1 DESCRIPTION There are several classes of problem with the current module versioning and searching, which will be discussed separately. The solutions proposed overlap, and are discussed in B below. =head2 Current Implementation Is Broken These problems are ones in which I would go so far as to say that the current (C) performance is actually broken. =head3 Discovery Of Older Versions Aborts Searches Currently a statement use foo 1.2; can cause C to search C<@INC> until it finds a C file or exhausts the search path. When a C, its C is checked against the one requested in the C statement. If the C version is less than 1.2, C immediately gives an error message and halts the compilation. A satisfactory version may exist elsewhere in C<@INC>, but it is not searched for. =head3 First Module Discovered May Not Be Newest I believe that when a programmer writes use module; `Do What I Mean' should find the newest version of the module present on the C<@INC> search path. Instead, the very first C file found is taken, regardless of the presence of others on the path. =head2 Current Methods Are Insufficient for Complex Installations Deployment of perl modules in high-reliability or widely shared environments often requires multiple versions of modules installed simultaneously. (Comments `but that's a bad idea' will be cheerfully ignored -- if I could control what other departments need, I would). This leads to an endless proliferation of C directories and ever-more-pervasive `silos of development.' Part of the problem is the limitations of the current system in how modules are versioned and how C decides which version to load. In worst case, code such as use lib '/path/to/department/module/versionX'; use module ;# To get version X for sure no use lib '/path/to/department/module/versionX'; has been found in production equipment. Why does such bogosity occur? It's an attempt to solve both the above problems and the deployment issues which follow below. =head3 New Module Releases Can Break Existing Scripts I An application which does its job well will live as long as the problem it addresses. This means old code may continue running for a long time. For C itself, most sites solve this problem by having the perl invocation include versioning: #!/usr/bin/perl5.005 The indicated version will likely remain installed and stable as long as the script which uses it and the platform on which that script runs. The proliferation and increasing use of modules is generally a good thing. However, installation of new modules can and sometimes does break existing scripts. Workarounds for this problem are cumbersome at best, and we have existence proofs in other languages that this can be handled better (notably C, but there are probably more). =head3 Test Systems Need Test Modules Mission-critical scripts often need to have a final test pass by releasing experimental versions onto productions systems alongside the production systems. The inflexibility of perl module versioning also contributes to difficulties in releasing systems for test. A new script may require significant changes to internals of one or more supporting modules. The changes need not be visible to existing scripts; if bugs are introduced then previously working systems may change or break in obscure ways. Ideally, there would be a mechanism by which C> or Cscript> could be released simultaneously with an appropriate version of C.pm> or Cmodule.pm> while the previous version remains in place for older code. A more flexible mechanism for module version specification and searching can fix the problem. =head2 Proposed Solution I believe that relatively simple changes can be made to the version identification and module installation systems which will solve all the above problems. In addition, those changes should be largely upward compatible from current functioning; and if needed could be made 100% compatible. =head1 IMPLEMENTATION Several changes, working together, should provide the
RFC 81 (v1) Lazily evaluated list generation functio
($start:&gen:$steps);
As before, $start is required (but need not be an integer). &gen takes one
parameter, which is the value of the previous element. For example:
@first5PowersOf2 = (1:sub {$_[0]**2}:5); # (1,2,4,8,16)
Because lists are memoized automatically, when we later say:
print $powersOf2[4];
The value of $powersOf2[4] is pulled from the memoization cache rather
than recalculated. What's more:
print $powersOf2[5];
is calculated from $powersOf2[4], rather than having to recalculate all
the in-betweens again, because of that caching.
This form of list generation can not generate the Fibonnaci sequence,
because it is not defined by a single $start, and it has more than
one parameter in its generator function. This requires a more
generalised form:
((@start):&gen:$num_steps)
which allows us to say:
@fib = ((1,1): ^_ + ^_: 5); # (1,1,2,3,5)
if we use the higher-order function notation proposed in RFC 23.
=back
=head1 IMPLEMENTATION
Some list generation functions can be short-circuited. For instance,
although (1..10:5) is just a shorthand for (1:^_+5:10), if it was
implemented this way then:
@a = (0..:5);
print $a[9];
would take an awfully long time to run and would memoize $a[0..8],
which probably isn't ideal. So slices and normal lists (at the very least)
should know that {0+5+5+5...+5} can be quickly calculated as {5*n}. There
may be other functions that can short-circuit as special cases, but that
is starting to sound complex.
It will be common in numerical programming to see multiple layers of
indirection:
@a = (1:5:10);
@b = getBigImage();
@c = @a(@b);
print $c[5];
In these cases Perl should consolidate as much as possible at compile time
to avoid too much overhead.
Dan Sugalski's comments on perl6-internals provide some insight about
potential lazy evaluation and memoization approaches:
=over 4
=item *
I was thinking we might keep a bitmap for used/unused cells (with unused
doubling as undef) and a two-level array pointing to chunks of real
elements/element pointers.
So, for example, if you did a:
$foo[$elem];
perl would first check bit $elem to see if that element is in use. If
so, it'd do a ($elem / chunk_size) to get the index to the chunk
pointer in the array structure, then access element ($elem %
chunk_size) to get a pointer to the ultimate thing. (Or the thing
itself, if it were an int, say)
Other methods are possible, of course, and which would be a win depends on
your element distribution. (A linked list would be a win for very sparse
arrays--$foo[time])
=back
=head1 REFERENCES
RFC 24: Semi-finite (lazy) lists
Memoization in Perl:
http://www.plover.com/~mjd/perl/MiniMemoize/
List comprehension in Haskell:
http://www.numeric-quest.com/haskell/hcompanion/principles.html#List
comprehension
Fethi Rabhi and Guy Lapalme: I,
Addison-Wesley, 235 pages, paperback, 1999. ISBN 0-201-59604-0
=head1 ACKNOWLEDGEMENTS
Damian Conway: Reviewed first draft
Karl Glazebrook: Suggested splitting from infinite lists proposal
Christian Soeller: Original 'slice' RFC; suggested argument reordering
Dan Sugalski: Implementation ideas
RFC 93 (v1) Regex: Support for incremental pattern m
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Regex: Support for incremental pattern matching
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 11 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 93
=head1 ABSTRACT
This RFC proposes that, in addition to strings, subroutine references may be
bound (with =~ or !~ or implicitly) to a regular expression.
=head1 DESCRIPTION
It is proposed that the Perl 6 regular expression engine be extended to
allow a regex to match against an incremental character source, rather than
only against a fixed string.
Specifically, it is proposed that a subroutine reference could be bound
to a regular expression:
sub {...} =~ /pattern/;
As the regular expression is matched, it would make calls to the subroutine
to request additional characters to match, or (after it has matched) to
return any unused characters.
When the regex engine requires additional characters to match, the
subroutine would be called with a single argument, and would be expected
to return a character string containing the extra characters. The single
argument would specify how many characters should be returned (typically
this would be 1, unless internal analysis by the regex engine can deduce
that more than one character will be required). Returning fewer than the
requested number of characters would typically indicate a premature
end-of-string and would probably trigger backtracking and/or failure to
match.
When the match is finished, the subroutine would be called one final time,
and passed two arguments: a string containing the "unused" characters (what
would be $' for a fixed string), and a flag set to 1. The subroutine
could use this call to push-back (or cache) unused data. In the case of
a failure to match (or success of the !~ operator), every character requested
during the match would be sent back.
A typical structure for a subroutine against which a regex was matched
would therefore be:
sub s {
if ($_[1]) {# "putback unused data" request
recache($_[0]);
}
else { # "send more data" request
return get_chars(max=>$_[0])
}
}
=head2 Examples
The most obvious example would be matching against an input stream:
sub { $_[1] ? $fh->pushback($_[0]) : $fh->getn($_[0]) } =~ /pat/;
which could also be written:
^1 ? $fh->pushback(^0) : $fh->getn(^0) =~ /pat/;
Of course, it would often be useful to have a subroutine that returns a
closure on a particular filehandle:
sub fhmatch { ^1 ? $_[0]->pushback(^0) : $_[0]->getn(^0) }
fhmatch($fh) =~ /pat/
fhmatch(\*STDIN) =~ /pat/
# etc.
In fact, this might be so commonly useful that matching against a
file handle should be made to work directly. That is:
$fh =~ /pat/
\*STDIN =~ /pat/
One could then do interactive lexing cleanly:
until (eof $fh) {
switch ($fh) {
/^\s*/; # skip leading whitespace
case /^(lexeme1)/ { push @tokens, $1=>LEX1 }
case /^(lexeme2)/ { interact_somehow }
case /^(lexeme3)/ { push @tokens, $1=>LEX3 }
# etc.
}
}
Note the use of the proposed PAIR data structure to store tokens
in the above example.
Because the character source is a subroutine, one could also match against
data coming out of a socket:
my $cache = "";
sub matching_socks {
if ($_[1]) { $cache .= $_[0]; return } # putback
if (length($cache) < $_[0]) { # not enough cached
my $extra; # so get some more
recv(SOCKET, $extra, $_[0]-length($cache));
$cache .= $extra;
}
return substr($cache,0,$_[0],"");
}
switch (\&matching_socks) {
case /pat1/ { action1() }
case /pat2/ { action1() }
case /pat3/ { action1() }
#etc.
}
or any other source:
sub mega_ape {
return join "", map {['a'..'z',(' ')x6]->[rand 32]} (1..$_[0])
unless $_[1]
}
\&mega_ape =~ /Now is the Winter of our discontent.../i;
print "Art after ", length($`), "chars\n";
=head1 IMPLEMENTATION
Dammit, Jim, I'm a doctor, not an magician!
Probably needs to be integrated with IO disciplines too.
=head1 REFERENCES
RFC 22 : Builtin switch statement
RFC 23 : Higher order functions
RFC 84 : Replace => (stringifying comma) with => (pair constructor)
RFC 94 (v1) Rename @ARGV to @ARGS
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Rename @ARGV to @ARGS =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 11 Aug 2000 Version: 1 Status: Developing Mailing List: [EMAIL PROTECTED] Number: 94 Perl isn't C. Time to get over it. :-) =head1 DESCRIPTION @ARGV is Perl's version of something like C's argv/argc. However, I would argue its naming is bad, because: 1. It isn't used like and doesn't behave like C's argv/argc in many circumstances 2. There's no $ARGC to go with it 3. It's not a word or anything close to a word 4. Perl isn't C (thank heavens!) 5. @ARGV makes little sense to people (like me) from a sh/ksh background @ARGS is a better choice for several reasons: 1. It's closer to a word and so is faster to read [1] 2. It's easier to explain and remember "Your command-line args are contained in @ARGS" 3. When you say "$var = $ARGS[2]" it's easier to glance at and tell what you're getting quickly 4. It makes it more consistent with other word-like Perl vars like $VERSION. 5. There's no expectation that it works like or should be used like C's argv/argc I don't feel this is changing something just for the sake of changing something. I think it actually helps clarify a key difference between Perl and C. However, feel free to disagree with me. Be nice. ;-) =head1 IMPLEMENTATION Change @ARGV to @ARGS. Make sure that the translator changes any code references in a person's script too. Make sure shift works on @ARGS, etc, etc. =head1 NOTES [1] This is true. I did a lot of work in cognition and artifical intelligence in college. Your brain reads words and legal word-like constructs about 3 times faster than non-words, even if there's only a one or two character difference. For example, you'd read "fleggies" much faster than "fleggitg". Kind of neat, eh? =head1 REFERENCES
RFC 48 (v2) Replace localtime() and gmtime() with da
named 'day' and 'month', in my opinion, rather than simply adding duplicate names for this information. =head1 CHANGES 1. Removed custom timezone determination. Sorry, better for a module. 2. Split C into C and C to mirror current functions. 3. Removed many extraneous functions from object. 4. Changed C<$obj->date> method to accept a C. 5. Added provisions for use of C<$obj->STRING> to change date object into string on-demand. 6. Added fractional seconds (fsec). 7. Changed return order in LIST context 8. Reverted to GMT from UTC since most systems are internally maintained in GMT, not UTC. 9. Axed date arithmetic =head1 REFERENCES Matt Sergeant's great Time::Object CPAN module Larry Wall's post of 8 Jan 2000 on deprecating localtime: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-01/msg00241.html RFC 49: Objects should have builtin stringifying STRING method =head1 ACKNOWLEDGEMENTS Jonathan Scott Duff, Tim Jenness, Johan Vromans, and perl6-language for great feedback. Russ Allbery and John Tobey for suggesting parts to slice-and-dice.
RFC 91 (v1) Builtin: partition
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtin: partition
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 11 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 91
=head1 ABSTRACT
It is proposed that a new function, C, be added to Perl.
C would return @list broken into
references to sub-lists, each one $list_size in size.
=head1 DESCRIPTION
In order to work with lists of arbitary size, it is often necessary to
split a list into equal sized sub-lists. A C function is
proposed that achieves this:
@list = (1,2,3,4,5,6);
@partitioned_list = partition(2, \@list); # ([1,2],[3,4],[5,6])
This is useful to provide tuples to functions that can operate on lists of
lists, for instance:
@sum_pairs = map {$_->[0] + $_->[1]} @partitioned_list; # (3,7,11)
If the list to be unzipped is not an exact multiple of the partition size,
the final list reference is not padded. For example:
@list2 = (1..7);
@partitioned_list2 = partition(3, @list2); # ([1,2,3], [4,5,6], [7])
C (see RFC 90) and C can work together to allow manipulation
of arbitary sized lists. For instance, we can extend the $sum_xy function
used as an example in the C RFC, which takes two lists and returns
the sum of them multiplied together component-wise:
$sum_xy = sub {reduce ^last+^x*^y, zip($_[0], $_[1])};
to a function $sum_mult that does the same with an arbitary number of
lists:
# Multiply all the elements of a list together, returning the result
$apply_times = reduce (^total * ^element, @^multiplicands);
# Swap the rows and columns of a list of lists
$transpose = partition(
# Find the size of each column
scalar @^list_of_lists,
# Interleave the rows
zip(@^lists_of_lists);
)
# Take a list of references to lists, multiply them component-wise,
# and return their sum
$sum_mult = reduce (
^total + $apply_times->( @^next_list ),
$transpose->(^list_of_lists),
);
# Example usage of $sum_mult
@a = (1,3,5);
@b = (2,4,6);
@c = (-1,1,-1);
$answer = $sum_mult->(\@a, \@b, \@c); # 1*2*-1+3*4*1+5*6*-1 = -20
=head1 IMPLEMENTATION
The C functions should be evaluated lazily. Because it is used
in common operations such as the transposition of a matrix, its efficiency
is particularly important.
=head1 REFERENCES
RFC 23: Higher order functions
RFC 76: Builtin: reduce
RFC 90: Builtins: zip() and unzip()
=head1 ACKNOWLEDGEMENTS
Damian Conway: Numerous comments on first draft
RFC 79 (v2) Perl Compiler is Just Another Pod Proces
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Perl Compiler is Just Another Pod Processor =head1 VERSION Number: 79 Version: 2 Date: 9 Aug 2000 Last-Modified: 11 Aug 2000 Maintainer: John Porter <[EMAIL PROTECTED]> Mailing List: [EMAIL PROTECTED] =head1 ABSTRACT With the perl compiler designated as Just Another Pod Processor, and the POD markup syntax generalized to allow direction to more than one processor, executable code can be inserted into POD-generated documentation. =head1 DESCRIPTION As of Perl 5, any chunk of source text is either POD, or executable code. This RFC proposes that, with respect to POD, the perl compiler act as plain ol' POD processor. Furthermore, the POD markup syntax should be extended to allow "output" to any combination of processors to be turned on or off at will. =head1 CHANGES Version 1 of this RFC was entitled "Code which is both executable and POD." Version 1 of this RFC proposed a special "perl" POD processor type. This version makes the "perl" type non-special. Version 1 proposed a simple implementation which could theoretically work with the perl5 front end. This version presumes that the perl6 front end is game for any implementation details necessary to support the proposal. =head1 IMPLEMENTATION The POD specification is modified from its perl5 form, to include the ability to put any number of POD processor names on the C<=for>, C<=begin>, and C<=end> lines. In addition, three POD processor names are reserved: C<"perl">, C<"all">, and C<"pod">. C<"perl"> is the name for the perl compiler; C<"all"> is an alias for all POD processors; and C<"pod"> is an alias for all POD processors except C. Furthermore, the standard POD tokens C<=pod> and C<=cut> are defined as being equivalent to C<=begin pod> and C<=end pod>, respectively. Alternatively, C<=pod> and C<=cut> could be dropped altogether. Note that the lists of processors turned on/off by any C<=begin/=end> directive are additive. Unless you have a better idea... :-) Example: =begin pod This will appear in all pod-generated documentation, but is ignored by perl. =begin all # This is seen by perl AND appears in pod. =end pod # this is seen only by perl. =begin pod # This is seen by perl too! =end pod =head1 REFERENCES RFC 5: "Multiline Comments for Perl" RFC 11: "Examples encoded with =also for|begin|end POD commands" RFC 44: "Bring Documentation Closer To Whatever It Documents" perlpod manpage for discussion of POD.
RFC 54 (v1) Operators: Polymorphic comparisons
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Operators: Polymorphic comparisons
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 7 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 54
=head1 ABSTRACT
This RFC proposes that numeric comparison operators default to stringwise
comparison when both arguments are non-numeric strings.
=head1 DESCRIPTION
Currently the expression:
"cat" == "dog"
returns true.
It is proposed that if I argument of a numeric comparison
operator can be converted to a number, rather than both being converted
to zero, the two operands should be compared using the equivalent
stringwise comparison operator.
It is further proposed that the current warning:
Argument "%s" isn't numeric
be changed to:
Arguments of "%s" aren't numeric - using string comparison instead
=head1 RATIONALE
Perl has excellent support for generic programming, because of its dynamic
typing, generic data types, and interface polymorphism. Just about the only
place where that DWIM genericity breaks down is in comparisons.
It is difficult to construct many generic algorithms and data structures
in Perl, because there is no generic way to specify an ordering on
dynamically typed data. For example, one cannot simply code a
generic BST insertion method:
sub insert
{
my ($self, $key, $value) = @_;
if (!defined($self->{key}))
{
$self->{key} = $key;
return $self->{value} = $value;
}
my $compare = $key <=> $self->{key};
return $self->{value} = $value unless $compare;
$self->{$compare} = $self->new() unless $self->{$compare};
return $self->{$compare}->insert($key,$value);
}
This will work well for numeric keys, but fail miserably on most
string-based keys, because <=> will generally return 0 for most pairs of
strings.
The above code would work correctly however if <=> detected the string/string
comparison and automagically used cmp instead.
=head1 IMPLEMENTATION
Dammit, Jim, I'm a doctor, not an engineer!
=head1 REFERENCES
Chapter 12 of "Object Oriented Perl"
RFC 55 (v1) Compilation: Remove requirement for fina
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Compilation: Remove requirement for final true value in require'd and do'ed files =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 7 August 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 55 =head1 ABSTRACT This RFC proposes that files compiled via a C or a C no longer be required to end in a true value. =head1 DESCRIPTION It is proposed that the final value in a file that is compiled using C or C no longer be significant. Instead it is proposed that files that wish to fail during compilation should throw an exception. Furthermore, any valueless exception (i.e. thrown with a simple C) that propagates through a C or C should automatically take the appropriate message string: "require failed: file "%s" threw an exception" "do failed: file "%s" threw an exception" Note that exceptions with some value would be passed through unchanged, allowing a compiled file to signal exactly why it failed. =head1 IMPLEMENTATION Dammit, Jim, I'm a doctor, not an engineer!
RFC 56 (v1) Optional 2nd argument to pop() and shift
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Optional 2nd argument to pop() and shift() =head1 VERSION Maintainer: Jonathan Scott Duff <[EMAIL PROTECTED]> Date: 7 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 56 =head1 ABSTRACT The inverse operations to C and C both accept a LIST to "add" to an array, yet C and C only remove B element from an array. In the interest of symmetry and TMTOWTDI, C and C should allow the programmer to remove multiple items from an array. =head1 DESCRIPTION The intent should be obvious, but I'll point it out anyway. =head2 pop The documentation for Perl 5.6.0 states that pop has one of two forms: C, or just C. This RFC proposes that a third form be added to C =over 4 =item pop ARRAY, EXPR EXPR would be evaluated to determine the number of elements to remove from the end of ARRAY and that number would be removed and returned. Thus C would be a more natural inverse to C (If you can add multiple elements to an array with C, why can't you remove multiple elements from an array with C?) =back This functionality can currently be accomplished with C, but it is non-obvious that C should be the routine to call and the method isn't at all intuitive. To "pop" the last $N items off of the end of an array using C, the call looks like this: splice @array, -$N; # remove the last $N items contrast to the more natural looking pop @array, $N; # remove the last $N items =head2 shift The semantics for C are similar to C except that it operates on the other end of the array. C also suffers from the inability to shift more than one element from the array. Just like C, the two forms of C are a C, and just plain C. This RFC proposes that a third form be added: =over 4 =item shift ARRAY, EXPR EXPR would be evaluated to determine the number of elements to remove from the beginning of ARRAY and that number would be removed and returned. Thus, C would be a more natural inverse to C. (If you can add multiple elements to an array with C, why can't you remove multiple elements with C?) =back As with C the proposed semantics can be accomplished with C and are just as un-intuitive: splice @array, 0, $N; # remove the first $N elements contrast to shift @array, $N; # remove the first $N elements =head2 Random examples @numbers = 1..10; $ten = pop @numbers;# still works @popped = pop @numbers, 3; # Take away 7, 8, 9 push @numbers, @popped; # Put 'em back @popped = pop @numbers, 0; # Nothing happens @popped = pop @numbers, 9; # And then there were none. @numbers = 1..10; @popped = pop @numbers, 100;# And then there were none but # @popped only has 10 things @numbers = 1..10; $one = shift @numbers; # still works @shifted = shift @numbers, 3; # Take away 2, 3, and 4 unshift @numbers, @shifted; # Put 'em back @shifted = shift @numbers, 0; # Nothing happens @shifted = shift @numbers, 9; # And then there were none. @numbers = 1..10; @shifted = shift @numbers, 100; # And then there were none but # @shifted only has 10 things =head1 IMPLEMENTATION I don't know the gory details other than it should be possible. However, there is one implementation detail that occurs to me: What should happen when the expression given to C, or C evaluates to a negative number? I see three options: 1) Nothing. We can only pop/shift positive amounts 2) Act as if the number were positive (i.e. abs(EXPR)) 3) C would then act as C and C would act as C The author of this RFC sees arguments for all three. =head1 REFERENCES The Perl 5.6.0 documentation L L L
RFC 53 (v10) Built-ins: Merge and generalize C
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Built-ins: Merge and generalize C and C =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 7 August 2000 Version: 10 Mailing List: [EMAIL PROTECTED] Number: 53 =head1 ABSTRACT This RFC proposes that the C and C functions be merged and generalized, by adding a fourth parameter to C. =head1 DESCRIPTION At present C only returns the index of the first occurrence of a specified substring. It is proposed that C take a fourth parameter telling it which occurrence of a specified substring to locate: $first = index $string, $substring, 0, 1; # first occurrence $first = index $string, $substring, 0, 2; # second occurrence $first = index $string, $substring, 0, 3; # third occurrence If omitted, this fourth parameter would default to 1, thus preversing the current behaviour. The C function would be unnecessary, being replaced by: $last = index $string, $substring, -1, -1; # last occurence =head1 IMPLEMENTATION Dammit, Jim, I'm a doctor, not an engineer!
RFC 65 (v1) Add change bar functionality to pod
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Add change bar functionality to pod =head1 VERSION Maintainer: Dan Sugalski <[EMAIL PROTECTED]> Date: August 08, 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 65 =head1 ABSTRACT Documents change, and change bars are a nice way to indicate what's changed. This RFC suggests a way to indicate the changed parts of a document that POD2whatever translators can mark appropriately. The change bars should also be distinct to the reader of the raw POD. =head1 DESCRIPTION Making what's changed in documentation stand out's quite useful, something I'm coming to appreciate more and more as the RFCs are flying back and forth. The standard way to do this is to mark the changed sections with one or more vertical bars on the left margin. Since changes can themselves be changed, multiple levels of change bar can occur. This mirrors the common practice in printed documentation. =head1 IMPLEMENTATION The pod parser modules look for the sequence /^|+\s/ at the beginning of a line and, if it's there, that line is considered as changed. The number of bars in front of a line indicates the number of bars in front of the text in the formatted output. If, when outputtiing a line, there is any changed text in it, then the entire line is marked as changed. So, for example, if the POD looked like: this is | a line the output would be: | this is a line since at least one character on the formatted version was changed. =head1 REFERENCES Every piece of good documentation for version 1.1 or higher of something.
RFC 72 (v1) The regexp engine should go backward as
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE The regexp engine should go backward as well as forward. =head1 VERSION Maintainer: Peter Heslin <[EMAIL PROTECTED]> Date: 9 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 72 =head1 ABSTRACT It is proposed that the regular expression engine should be designed so that, when it is in an accepting state, it will either consume the character after the end of the currently matching part of the target string, or the character just before its beginning, depending on instructions embedded in the regexp itself. =head1 DESCRIPTION The way humans scan text for a pattern is often to look for a distinctive feature of the pattern sought, and then to look at the surrounding context before and after. The Perl regular expression engine is optimized to look such fixed string landmarks in this way, but if you want to write a hand-optimized regexp that will explicitly look backward from a certain match in this fashion, your lookbehind is limited to fixed-length expressions (at least in my Perl 5.005, and I assume this true for 5.6, too). A more general approach than lookbehind might be useful. I propose two new regexp extensions which mean "jump and reverse" and "jump and go forward". These might be (?r) and (?f) or (?[) and (?]) respectively, or some other pair. It is important to note that this proposal does not suggest that the same characters in a string should be matched twice or more in a single hit by different parts of the same regexp going in different directions; that way madness lies. The "jump" part of these commands means to jump immediately to the beginning or the end of the currently matched part of the string and continue from there. In this way, the match continues to grow one character at a time, but at both ends. =head2 Usefulness The Perl regexp engine is excellent at finding fixed strings embedded in your regexp and starting from there, but, as Friedl says in his book, it is generally more efficient if you can guide a regular expression engine yourself based upon your knowledge and assumptions about the potential input. Imagine a very long input string containing data such as this: ... GCAAGAATTGAACTGTAG ... If you want to match text that includes the string GAAC, but only when it follows GAATT or any one of a large number of other different possibilities, you could (a) code the whole match, including all the possibile prefixes, into the regexp or (b) use GAAC as the match string and then select the particular hits you want by positive and negative lookbehind. For some large amounts of data and very complex matching requirements that come before any fixed string, Perl's optimizer can't do as well as a human and option (b) can (in my experience, anyway) be an order of magnitude faster. The problem is that with only fixed-length lookbehind available this is often not a practical option. With the proposed extension, you could write: m/GAAC(?r)(TTAAG| )/ and the regexp engine doesn't have to go looking deep into your regexp to know where it should start potential matches. As a frivolous illustration, the string ABCDEFGHIJKLM would be matched by: m/FG(?r)EDCB(?f)HIJK(?r)A^(?f)LM$/ =head2 Related Features It will be important to know the offset where the match begins, as well as where it ends (indeed it would be nice to have that info in Perl5 without having to pay the C performance penalty), so in addition to C, there might be a function C to give the start of the match -- or C might return both end and start offsets in a list context. It would be very nice if C<(?r)> would do something usefully optimized if it appeared at the start of a regexp: C would then start matching at the end of the string and proceed rapidly towards the front, until it hit "ABC". This could be particularly useful in conjunction with C. It would be extra work, however, as not only would the regexp engine itself have to be modified to switch direction, but the code that "cheats" by looking for likely places to start the engine (which presumably uses a Boyer-Moore or similar algorithm) would have to run backward, too. I have no idea whether this feature will help people parsing right-to-left languages; it seems likely to help with bi-directional texts (see RFC 50). =head1 IMPLEMENTATION It may already be clear that the author of this RFC has no idea of how the Perl regexp engine is implemented. I have never even looked at the code of this or any other regexp engine, nor am I competent to do so. It may well be, therefore, that what I propose is completely infeasible. If so, and those who are actually going to code this stuff say so, I will promptly withdraw this RFC, which in the cirumstances may turn out to have been a Request For Crucifixion. Here are some potential implementation issues: =head2 Backtracking Presumably, the regexp engine maintains something lik
RFC 67 (v1) Deep Copying, aka, cloning around.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Deep Copying, aka, cloning around.
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 67
=head1 ABSTRACT
Perl should have a C method for deep copying of hierarchical data
structures.
Damian Conway mooted a C function for deep copying of objects as
part of an earlier discussion. This RFC expands upon that and gives it
special attention. I expect several iterations of this RFC from feedback.
=head1 DESCRIPTION
The language interface is the C method which takes an object as
argument and returns a copy of it as result:
=over 4
=item clone SCALAR
=item clone SCALAR, CALLBACK
$copy = clone($obj)
$copy = clone($obj, sub { die 'Filehandle copying not allowed' })
The C is an optional function to be called if C encounters
a filehandle. It will either throw an exception or return a value to be
used as the cloned filehandle.
=back
=head1 IMPLEMENTATION
=head1 Default
The default functionality will switch on C and recursively
create new data structures in the way many people have written themselves:
(/^$/ || /^CODE$/) && return $obj;
/^SCALAR|REF$/&& return \clone $$obj;
/^ARRAY$/ && return [ map clone($_), @$obj ];
/^HASH$/ && return { map {$_, clone $obj->{$_}} keys %$obj };
TODO: behavior for C, C, and C.
=head2 Blessed objects
If C encounters a blessed object C<$obj> say, it will call
C<$obj->CLONE(CALLBACK)>. If the C method is not defined in
C<$obj>'s class or any of its superclasses, C will carry
out the default functionality on the internal representation of C<$obj>.
Classes (e.g., DBI) may well choose to throw an exception in their C
methods.
=head2 Filehandles
If C encounters an C, its default behavior will be to
make a copy of the filehandle (debatable: perhaps the default should be to
throw an exception) unless a C function was specified
=head2 Tied variables
If C encounters a tied variable, it will call the C method in
that class or fall back to C. (Note: perhaps all missing
functions from tied classes should punt to C. But that is
outside the scope of this RFC.)
=head2 Cyclic references
The C function should detect circular references and replicate the
same structure in the copy. One implementation that suggests itself is to
keep a hash of input references with output references as values. It has
been suggested that the code to do this will already be available in the
garbage collector.
=head2 Exceptions
If an exception is thrown anywhere during the copying, it needs to be
trapped so that C can clean up any cyclic references it has created,
then rethrown.
=head1 REFERENCES
None.
RFC 68 (v1) Eliminate the optional C for C
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Eliminate the optional C for C etc block declarations =head1 VERSION Maintainer: Peter Scott <[EMAIL PROTECTED]> Date: 8 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 68 =head1 ABSTRACT The C keyword is currently optional on C, C, C, C. Almost certainly no-one ever uses it. It should be eliminated as an option. =head1 DESCRIPTION C etc have special semantics making them different from ordinary subroutines; telling the user that they can use the C keyword gives a false impression. =head1 IMPLEMENTATION Obvious. =head1 REFERENCES L
RFC 67 (v2) Deep Copying, aka, cloning around.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Deep Copying, aka, cloning around.
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last-Modified: 12 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 67
=head1 ABSTRACT
Perl should have a C method for deep copying of hierarchical data
structures.
Damian Conway mooted a C function for deep copying of objects as
part of an earlier discussion. This RFC expands upon that and gives it
special attention. I expect several iterations of this RFC from feedback.
=head1 DESCRIPTION
The language interface is the C method which takes an object as
argument and returns a copy of it as result:
=over 4
=item clone SCALAR
=item clone SCALAR, CALLBACK
$copy = clone($obj)
$copy = clone($obj, sub { die 'Filehandle copying not allowed' })
The C is an optional function to be called if C encounters
a filehandle, dirhandle, or object with magic or an XS implementation. It
will either throw an exception or return a value to be used as the cloned
filehandle.
=back
=head1 IMPLEMENTATION
=head2 Default
The default functionality will switch on C and recursively
create new data structures in the way many people have written
themselves. Here, for instance, is Garrett Goebel
(C<[EMAIL PROTECTED]>)'s version implementing circular reference checking:
our %SEEN = ();
our $DEPTH = 0;
sub clone { # Dereference and return a deep copy of whatever's passed
our %SEEN;
local $_ = ref($_[0]) or return $_[0];
exists $SEEN{$_} and return $SEEN{$_};
$DEPTH++;
my $rval =
/^HASH$/ ? {map {clone($_)} (%{$_[0]})}
: /^ARRAY$/ ? [map {clone($_)} @{$_[0]} ]
: /^SCALAR$/ ? \${$_[0]}
: /^FORMAT$/ ? $_[0] # Shallow copy until we figure out
: /^Regexp$/ ? $_[0] # B.pm and Class::Tom show the way
: /^REF$/? $_[0] # how to deep copy these. Note:
: /^IO$/ ? $_[0] # "
: /^GLOB$/ ? $_[0] # "
: /^CODE$/ ? $_[0] # " (B::Deparse)
: $_[0]->CLONE;
--$DEPTH
and $SEEN{$_} = $rval
or %SEEN = ();
$rval;
}
=head2 Blessed objects
If C encounters a blessed object C<$obj> say, it will call
C<$obj->CLONE(CALLBACK)>. If the C method is not defined in
C<$obj>'s class or any of its superclasses, C will carry
out the default functionality on the internal representation of
C<$obj>. Probably this will mean little more than calling C.
Classes (e.g., DBI) may well choose to throw an exception in their C
methods.
=head2 Filehandles
If C encounters an C, its default behavior will be to
make a copy of the filehandle (debatable: perhaps the default should be to
throw an exception) unless a C function was specified, in which
case it will use the return value of C.
=head2 Tied variables
If C encounters a tied variable, it will call the C method in
the class of the underlying implementation object or fall back to
C. (Note: perhaps all missing functions from tied
classes should punt to C. But that is outside the scope of this
RFC.)
=head2 Cyclic references
The C function should detect circular references and replicate the
same structure in the copy. One implementation that suggests itself is to
keep a hash of input references with output references as values. It has
been suggested that the code to do this will already be available in the
garbage collector.
=head2 Exceptions
If an exception is thrown anywhere during the copying, it needs to be
trapped so that C can clean up any cyclic references it has created,
then rethrown.
=head1 REFERENCES
The L module (http://search.cpan.org/doc/RAM/Storable-0.7.0/Storable.pm).
The L module
(http://search.cpan.org/doc/GSAR/perl-5.6.0/ext/Data/Dumper/Dumper.pm).
RFC 80 (v2) Exception objects and classes for builtins
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Exception objects and classes for builtins
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 9 Aug 2000
Last-Modified: 12 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 80
=head1 ABSTRACT
This RFC proposes that builtins that throw exceptions throw them as objects
belonging to a set of standard classes. This would enable an exception
type to be easily recognized by user code. The behavior if the exception
were not trapped should be identical to the current behavior (error message
with optional line number output to STDERR and exit with non-zero exit code).
=head1 DESCRIPTION
RFC 63 proposes a standard exception handling mechanism with syntax and
semantics adapted from Graham Barr's Error.pm. This allows code like
try {
# fragile code
} catch Exception::IO {
# handle IO exceptions
} catch Exception::Socket, Exception::FTP {
# handle network exceptions
} catch {
# handle other exceptions
}
Exceptions are objects blessed into classes the user names after the type
of exception; their attributes include text which will be be given to
C (one that won't be trapped) if the exception is uncaught. So
modules can throw exceptions without requiring that the user be trapping them.
Builtins experiencing fatal errors currently call C, which is to say,
they throw an exception. Builtins experiencing non-fatal errors return a
variety of error codes. RFC 70 proposes that these be trappable exceptions
if C is in effect.
This RFC proposes that both exceptions be objects blessed into a
standard set of classes which can be checked for by the user. This is much
cleaner than
eval {
# fragile code
};
if ($@) {
# play guessing games with regexen on $@
# and hope that the error message doesn't
# change in the next release.
}
Yes, this proposal is very Javaish. I don't do much programming in Java
but I like the way it does this.
=head2 Object Attributes
The exception object will have these attribute methods filled in by perl:
=over 4
=item id
Unique numeric identifier, assigned by perl developers. A number range
for user exceptions will also need to be provided. I am not going to
touch the issue of whether the perl developers should set up registries
for CPAN developers to grab ranges for their own exceptions.
=item message
The text of the exception, e.g., "Out of memory".
=item severity
Relative level of fatality. Chosen from some TBD enumeration.
=item line
Line number exception was thrown at.
=item file
File exception was thrown in.
=item data[(userdata)]
User data, arbitrarily complex. If the user knew the underlying object
implementation, of course they could stick in attributes with any names
they wanted; but nothing should rely on that, so this hook is provided.
=back
Stringifying the object itself will yield the C attribute. A
C attribute was suggested to indicate what part of perl is
throwing the exception: IMO that is covered in the exception class.
=head2 Classes
This is a strawman exception class enumeration. The merits of this RFC do
not depend on this being a good list, only on it being possible to
find a reasonable one. A common prefix like C is elided for
readability.
=over 4
=item Arithmetic
Divide by zero and friends.
=item Memory
C failed, request too large, that sort of thing.
=item Eval
A compilation error occurred in C, C, or C<(?{ ... })>. Possible
candidate for subdividing.
=item Regex
A syntax error occurred in a regex (built at run-time). Possible candidate
for subdivision.
=item IO
An I/O error occurred. Almost certainly should be subdivided, perhaps
parallel to the C hierarchy.
=item Format
Error in format given to C, C, octal/hex/binary number
etc. Could use a better name.
=item Thread
Some goof in threading.
=item Object
Tried to call non-existent method, that kind of thing.
=item System
Attempt to interact with external program failed (maybe it ran out of
process slots, that kind of thing).
=item Taint
Duh.
=item Reference
Attempt to dereference wrong kind of thing.
=item Recursion
Excessive subroutine recursion, maybe also infinite C or C
loops (although arguably they would throw a C exception).
=back
There are bound to be other categories that should be covered. This
is just to put meat on the bones. This is the province of librarians;
the fact that it's possible to argue endlessly about the choices doesn't
preclude coming up with good ones.
=head1 IMPLEMENTATION
This should not be construed as requiring that clearly fatal errors (e.g.
pointer corrupted) should be trappable, or throw O-O exceptions. Note that
compilation errors don't have to be classified.
Do we need to mention the C<$SIG{__DIE__} problem again?
=head1 REFERENCES
RFC 63
RFC 95 (v1) Object Classes
be to assign the parameters
passed to the object variables in the order defined within the class.
class User;
my ($id, $name, $email);
package main;
my $u = User.new('abw', 'Andy Wardley', '[EMAIL PROTECTED]');
RFC 57, "Subroutine prototypes and parameters", proposes named
parameters which might be useful in this context. The syntax is not
yet finalised and the proposal may never be officially adopted, but in
the case that it is, it might look similar to one of the following
examples:
# assume assignments within argument list are in object scope
my $u = User.new( $id = 'abw',
$name = 'Andy Wardley',
$email = '[EMAIL PROTECTED]' );
# use '=>' and apply parser magic to grok named parameters
my $u = User.new( $id => 'abw',
$name => 'Andy Wardley',
$email => '[EMAIL PROTECTED]' );
# many other possible forms... suggestions to perl6-language-subs
This would allow construction of sparse objects (i.e. in which only
some attributes are set) and hopefully make it easier to remember
attributes by name rather than position.
Note that we have to consider how array or hash array attributes might
'gobble up' all remaining arguments.
class Author;
my ($name, @books);
package main;
my $dna = Author.new('Douglas Adams',
'Hitch-Hikers Guide to the Universe',
'The Restaurant at the End of the Universe',
...);
This is effectively the same issue as for subroutine prototypes. It is
discussed further in RFC 57.
=head2 Accessing Object Variables
Object variables are accessed or updated in the same way as class
variables, by using the dot operator and specifying the object
reference as the receiver (on the left of the dot).
my $u = User.new('tom', 'Thomas Tank');
$u.email = '[EMAIL PROTECTED]';
print "Name: ", $u.name, "\nEmail: ", $u.email, "\n";
The object is effectively a fixed structure. Unlike a hash array
which is inherently adaptable, the object is limited to a restricted
interface. Any attempt to access undefined attributes will result in
a compile-time error (again, under control of the aforementioned
pragma or switch).
=head2 Calling Object Methods
Object methods are called using the same syntax as for accessing
attributes.
class User;
my ($id, $name, $email);
sub about {
# member variables are in scope
return "Name: $name\nEmail: $email\n";
}
package main;
my $u = User.new('dick', 'Dick Richards', '[EMAIL PROTECTED]');
print $u.about;
It is entirely intentional that the syntax for accessing attributes is
the same as for calling methods. To users of the class these should
be synonymous. This allows the designer of the class to change the
implementation (for example by changing an attribute to a method to
enable some new magic) without requiring any change in the user's
code.
It should be possible to define both a variable and method of the same
name. The dot operator should always call the method in preference to
accesing the attribute directly. Thus we can extend a class by wrapping
an existing attribute in an accessor method and have all existing
calls in user code forwarded appropriately.
class User;
my ($id, $name, $email);
our $domain = 'perl.org';
sub email {
# automatically generate $email if not defined
$email ||= "$id@$domain";
}
package main;
my $u = User.new('lwall', 'Larry Wall');
print $u.email; # prints "[EMAIL PROTECTED]"
It should be possible to define methods as lvalue subs so that they can
be used on the left hand side of an C<=> assignment. This achieves greater
equivalence with attributes. For example:
class User;
my ($id, $name, $email);
sub email : lvalue {
$email = shift || $email;
# do something clever
}
package main;
my $u = User.new('lwall', 'Larry Wall');
$u.email = '[EMAIL PROTECTED]'
=head2 Compound Dot Operations
It should be possible to chain multiple dot operations into a single
expression.
$foo.bar.baz = 10;
=head2 Internal Variables
Within a class definition, all variables are lexically scoped.
Within an object method, for example, the object variables are clearly
visible unless masked by other lexical variables in a narrower scope.
class User;
my ($id, $name, $email);
our $domain = 'nowhere.com';
sub summary {
# new $email lexical masks object variable
my $email = $email ||
RFC 73 (v1) All Perl core functions should return ob
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
All Perl core functions should return objects
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 08 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Status: Developing
Number: 73
=head1 ABSTRACT
In the past, Perl has only provided two return options for its builtin
functions: scalars or arrays. In a scalar context, only one select value
was returned, greatly impacting the functionality of the function
(unless you like pulling apart long lists).
The reason this was done was to allow easy access to scalar/string data.
However, objects can use the mechanism described in RFC 49 (or something
like it) to become strings on-demand in Perl 6. As such, we should make
all Perl functions return objects in a scalar context in Perl 6.
=head1 DESCRIPTION
When several of the mechanisms proposed in other RFC's combine, we have
the power in Perl 6 to pass I around as objects, converting
them to strings as they're needed. This gives us much power, since we
present both objects and "true" scalars to beginners and advanced Perl
users alike with one common set of functions. As such, objects are
embedded in Perl from the ground up.
Others have proposed typing objects, and extracting them that way:
my $uid = getpwnam $user;# "true" scalar uid
my pw $pw = getpwnam $user;# object of type "pw"
However, this has a couple problems:
1. You have to have the correct object class and, at
the very least, alter your script's syntax.
2. You can't make $pw look like $uid transparently.
Instead, having objects that walk and talk like scalars on demand is a
more powerful approach. Note that this RFC does not necessarily preclude
being able to type objects and pull out specific classes. The two
approaches could be combined, giving multi-class objects that can be
transparently accessed as "true" scalars.
We'll start out with complex examples, where it's obvious how this is a
benefit, and go down to simpler functions, where it might be less
obvious.
=head2 Complex Functions
Let's choose C, since it's an easy target. Currently, it only
returns one of two things:
1. A massive 13-element list (LIST context)
2. A boolean success/failure (SCALAR context)
Neither of these is particularly useful, unless you like pain. To get a
decent interface, you have to use C or some other module.
Instead, let's put an object-oriented interface in the core:
$stat = stat $file;# returns an object
@stat = stat $file;# legacy list (like current)
%stat = stat $file;# hash (see RFC 37)
print "$stat"; # calls $stat->STRING, which
# could print the filename or
# some other useful piece of info
Note that our legacy calling methods are unaffected, but we now have an
object too. The boolean truth value is simplistic to determine still,
you simply have to say:
$stat = stat $file or die "Can't stat $file: $!";
The object methods of the C<$stat> object are powerful enough that
kludges like C<_> no longer have to exist. Plus, you can stat multiple
files out of order and still get the benefits of cached C calls:
$f1 = stat $file1 or die;
$f2 = stat $file2 or die;
if ( $f1->size > 0 and $f2->owner == 0 ) {
print "root-owned $file1 is mode ", $f1->mode & 0;
if ( $f1->mtime > time ) {
# here, "$f1" is $f1->STRING == $f1->filename
warn "warning: bad mojo, $f1 has an mtime in the future!\n";
}
}
Now, we have a full object-oriented C implementation, wrapped in a
tidy function that can work just like Perl 5's if you want it to.
As a second example, let's examine C, whose return options
are:
1. A pretty dang big 9-element list
2. The numeric user id
C differs from C in that you have to actually use what
you get in a C context in many situations. However, this can be
fixed with an mechanism like that in RFC 49:
$pw = getpwnam $username; # get the object
print $pw->gcos, " is uid $pw"; # $pw->STRING could
# reference $pw->uid
Here, the legacy return value (numeric user id) is preserved. No need to
redo any of the documentation - but advanced users can be told "By the
way, $pw is actually an object..." and so on.
=head2 Medium-Level Functions
As a medium-level example, let's take C. At first, making what's
returned from C into an object might not seem to have much use.
However, consider how cool it would be if C maintained stuff like:
$fork = fork;# create a new process
$fork->pid # current pid
$fork->ppid # parent's process id
$fork->errno # EAGAIN, for example
$fork->is_parent # parent?
$fork->is_child # child?
Then, you could fork multiple times, without having to worry about
maintaining info on which fork is which - it's all right th
RFC 74 (v1) Proposal to rename C and C
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Proposal to rename C and C =head1 VERSION Maintainer: Jonthan Scott Duff <[EMAIL PROTECTED]> Date: 8 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 74 =head1 ABSTRACT C and C should be C and C respectively, in keeping with all of the other special-to-Perl names. =head1 DESCRIPTION The abstract says it all. =head1 IMPLEMENTATION Just change the names! =head1 REFERENCES Perl 5.6.0 documentation
RFC 23 (v2) Higher order functions
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Higher order functions
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 August 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 23
=head1 ABSTRACT
This RFC proposes some syntactic sugar to simplify the creation of
higher-order functions (a.k.a. "currying").
=head1 DESCRIPTION
One situation in which the proposed Perl C statement does not
provide a good substitute for a cascaded C, is where a switch value
needs to be tested against a series of conditions. For example:
sub beverage {
switch (shift) {
case sub{ $_[0] < 10 } { return 'milk' }
case sub{ $_[0] < 20 } { return 'coke' }
case sub{ $_[0] < 30 } { return 'beer' }
case sub{ $_[0] < 40 } { return 'wine' }
case sub{ $_[0] < 50 } { return 'malt' }
case sub{ $_[0] < 60 } { return 'Moet' }
else{ return 'milk' }
}
}
The need to specify each condition as an anonymous subroutine is tiresome.
Each of these small subroutines is really a "higher order" function, which
exists merely to bind the second operand of the
C> operator.
=head2 The anonymous placeholder
It is proposed that Perl reserve the bareword C<^_> (caret-underscore) as
a "placeholder" for generating higher order functions more cleanly.
That is, any expression containing C<^_> anywhere that a value might
appear, will be converted to "deferred expression": a reference to a
subroutine in which the placeholders are replaced by the appropriate
number and sequence of arguments.
That is, the expression:
$check = ^_ == ^_**2 *^_ or die ^_;
is equivalent to:
$check = sub (;) {
$_[0] == $_[1]**2 *$_[2] or die $_[3]
};
This could then be invoked:
$check->(@args);
It would also be possible to interpolate an argument list into a static
expression like so:
(^_ == ^_**2 *^_ or die ^_)->(@args);
=head2 Named placeholders
Those not currently studying or using geometry might not be too sure what
they're dealing with when they see:
$check = ^_ == ^_**2 *^_ or die ^_;
in a program. However, the following is self-documenting:
$check = ^cylinder_vol == ^radius**2 * ^height
or die ^last_words;
This uses the I notation. If two placeholders use the
same identifier, they refer to the same argument. Therefore, the following
is equivalent to the previous line:
$check = ^cylinder_vol == ^radius*^radius * ^height
or die ^last_words;
=head2 Positional placeholders
The order in which the arguments appear in a function may not be
convenient:
# getMeasurements returns ($height, $radius)
@measurements = getMeasurementsFromSomeplace();
$check->($volume, reverse(@measurements), 'Invalid measurements');
A convenient way around this is using I:
$check = ^3 == ^1**2 * ^2 or die ^4;
@measurements = getMeasurementsFromSomeplace();
$check->(@measurements, $volume, 'Invalid measurements');
Positional placeholders can be used to re-order named placeholders too:
$check = ^cylinder_vol == ^radius**2 * ^height
or die ^last_words;
$check2 = $check->(^3, ^1, ^2, ^4);
=head2 Combining placeholder types
Although not necessarily a good idea, these can be mixed in a single
higher-order function:
$icky_func = ^test ? ^2 * ^_ : ^3 * ^_;
First the positional placeholders are filled in (a higher numbered
positional placeholder than the number of parameters results in a
compile-time error). The anonymous and named placeholders fill in the
missing places in the order in which they appear, from left to right.
However, for the good of international mental health, users should be
encouraged to consider using a consistent approach within a single
higher-order function definition.
=head2 Examples:
With C<^_>, the previous ugly case statements can be rewritten:
sub beverage {
switch (shift) {
case ^_ < 10 { return 'milk' }
case ^_ < 20 { return 'coke' }
case ^_ < 30 { return 'beer' }
case ^_ < 40 { return 'wine' }
case ^_ < 50 { return 'malt' }
case ^_ < 60 { return 'Moet' }
else { return 'milk' }
}
}
Likewise a Tree class might provide a traversal callback like so:
$root = Tree->new(load_from => "datafile")
my $sum = 0;
$root->traverse( $sum += ^_ );
Higher order functions would also be very useful with the proposed
C function:
$sum = reduce ^_+^_ (0,@vals);
$prod = reduce ^_*^_ (1,@v
RFC 71 (v1) Legacy Perl $pkg'var should die
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Legacy Perl $pkg'var should die =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 08 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Status: Developing Number: 71 =head1 ABSTRACT Perl used to use $pkg'var instead of the modern $pkg::var. This is still in Perl 5. It's gotta go. (At least, it should.) =head1 DESCRIPTION See above. =head1 IMPLEMENTATION See above. =head1 REFERENCES Camel-3 p. 60 reminded me of this.
RFC 90 (v1) Builtins: zip() and unzip()
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtins: zip() and unzip()
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 11 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 90
=head1 ABSTRACT
It is proposed that two new functions, C, and C, be added to
Perl. C would return a list that interleaved
its arguments. C would reverse this operation.
=head1 DESCRIPTION
Miranda, the upcoming Python v2.0, and numerous functional languages use
a function called C to interleave the arguments of arrays together.
It is proposed that Perl implement this function, and evaluate it lazily.
For instance:
@a = (1,3,5);
@b = (2,4,6);
@zipped_list = zip(\@a,\@b); # (1,2,3,4,5,6)
This makes it easy to operate on multiple lists using flexible reduction
functions:
$sum_xy = sub {reduce ^last+^x*^y, zip($_[0], $_[1])};
print $sum_xy->(\@a, \@b); # Prints '44', i.e. 1*2+3*4+5*6
In order to reverse this operation we need an C function:
@zipped_list = zip(\@a,\@b); # (1,2,3,4,5,6)
@unzipped_list = unzip(3, \@zipped_list); # ([1,3,5], [2,4,6])
If the list to be unzipped is not an exact multiple of the partition size,
the final list references are not padded--their length is one less than
the list size. For example:
@list = (1..7);
@unzipped_list2 = unzip(3, \@list); # ([1,4,7], [2,5], [3,6])
=head1 IMPLEMENTATION
The C and C functions should be evaluated lazily.
Effectively, C creates an iterator over multiple lists. If used as
part of a reduction, the actual interleaved list need never be created.
For instance:
$sum_xy = sub {reduce ^last+^x*^y, zip($_[0], $_[1])};
$answer = $sum_xy->(\@a, \@b);
should be evaluated as if it read:
$answer = 0;
$answer += $a[$_] * $b[$_] for (0..$#a-1));
which does not need to create an intermediate list.
=head1 REFERENCES
RFC 23: Higher order functions
RFC 76: Builtin: reduce
RFC 70 (v1) Allow exception-based error-reporting.
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Allow exception-based error-reporting. =head1 VERSION Maintainer: Bennett Todd <[EMAIL PROTECTED]> Date: 8 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 70 =head1 ABSTRACT Allow full implementation of Fatal.pm, for programmers who prefer exceptions for error reporting. =head1 DESCRIPTION Perl has traditionally reflected the Unix syscall and library tradition for error reporting: errors are indicated by otherwise-impossible return values, which must be checked for explicitly, lest system error events be ignored. Some programmers prefer to have errors print a message and exit with non-zero status, by default, rather than having to always code " || die ...". In perl5 this has proven elusive of implementation. Fatal.pm has been the attempt made to date, and it suffers from two problems. One can be fixed with further development: it should have various lists of builtins available, e.g. :io, :system, :all for including all calls affecting I/O, all system calls of any sort, and all calls that can have error returns. If these were a success, then the requested category could also be posted into a testable variable, allowing module authors who wished to to automatically support this functionality as well. But Fatal.pm development stalls out early, because some builtins, which report testable error conditions, cannot be wrapped. A conspicuous example is print(). =head1 IMPLEMENTATION Ensure that every perl builtin that can return an error, can be wrapped. I don't know whether this is purely an implementation issue (and so lies solely in the domain of perl6-internals) or whether any programmer-visible changes may be necessary to allow this (justifying posting to perl6-language). =head1 REFERENCES Fatal.pm, as included with recent perls. application/pgp-signature [Press RETURN to save to a file]
RFC 59 (v1) Proposal to utilize C<*> as the prefix t
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Proposal to utilize C<*> as the prefix to magic subroutines
=head1 VERSION
Maintainer: Jonthan Scott Duff
Date: 7 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 59
=head1 ABSTRACT
Perl has always claimed the ALL-CAPS names for itself, I propose we
give them back to the programmer.
=head1 DESCRIPTION
Perl steals subroutine names from the programmer. By prefixing the
Perl-special subroutines with a character that is not a valid prefix
for Perl programmers, we separate what belongs to Perl and what
belongs to the user.
With the proliferation of special subroutine names (BEGIN, END, INIT,
CHECK, etc.) the all capital subroutine names available to the
programmer has steadily shrunk. Rather than stealing subroutines from
the programmer, we should create a space just for Perl.
sub *BEGIN {
# do compile-time stuff
# Perl-special
}
sub BEGIN {
# No relation to the former. Purely user space.
# The user may have his/her own reasons for naming his
# subroutines this way. (e.g., it fits the conception model
# that the software is build upon/around/through)
}
The visual distinction lets the programmer know that something special
is happening here and that this is not your average run-of-the-mill
subroutine.
Another area where could be useful is in conjunction with Damian
Conway's C proposal. As his proposal currently stands, the
programmer can not name a package LIST or SCALAR and use it with the
proposed C.
=head2 Examples
switch ([want]) {
case '*LIST'{ return @array; }
case '*SCALAR' { return $foo; }
case 'LIST' { return $MyListObj; }
}
sub *BEGIN { ... }
sub *END{ ... }
sub *INIT { ... }
sub *AUTOLOAD { ... }
sub *TIESCALAR { ... }
sub *FETCH { ... }
=head2 Potential problems
Makes Perl-special subroutines different from user subroutines. This
implies yet another special case.
=head1 IMPLEMENTATION
Um ... that's up to the internals people.
=head1 REFERENCES
Perl 5.6.0 documentation
RFC 21 (v1): Replace C with a generic C function
RFC 58 (v1) C changes.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
C changes.
=head1 VERSION
Maintainer: Ted Ashton <[EMAIL PROTECTED]>
Date: 7 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 58
=head1 ABSTRACT
The current return value of C is little-used and tends to confuse
those learning perl. Here is presented a change to C's return value
and to the CFILEHANDLEE)> construction.
=head1 DESCRIPTION
This RFC contains two proposed changes. First, as it is common to want to
removed newlines upon reading a file,
while (chomp()) {
. . .
}
should become the equivalent of
while () {
chomp;
. . .
}
or, to put it more explicitly,
while (defined($_ = )) {
chomp $_;
. . .
}
where the various equivalent constructions would, of course, work as expected.
Second, as it seems common for someone learning perl to expect
$without_newline = chomp($previous_form);
to put a copy of the text in C<$previous_form>, sans newline, into
C<$without_newline> while not modifying C<$previous_form>, Perl should
do just that.
C called in void context would remove the newline
from the variable (or members of the list) upon which it was called.
C called in a scalar context would leave its argument variable
untouched and instead return a Ced version of that variable's
contents. Likewise and furthermore for other contexts.
=head1 IMPLEMENTATION
As I know little about perl5 internals and even less about perl6, I shall
simply present the following notes:
=over 4
=item *
This proposal does not speak to what should happen with C.
=item *
The proposed demise of C<$/> and stated determination that there will be no
default filehandle will have an effect on C. After all, that's how
it determines which character to seek at the end of the line.
=back 4
=head1 REFERENCES
The Camel II, pp 53 and 149.
RFC 80 (v1) Exception objects and classes for builti
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Exception objects and classes for builtins
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 9 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 80
=head1 ABSTRACT
This RFC proposes that builtins that throw exceptions throw them as objects
belonging to a set of standard classes. This would enable an exception
type to be easily recognized by user code. The behavior if the exception
were not trapped should be identical to the current behavior (error message
with optional line number output to STDERR and exit with non-zero exit code).
=head1 DESCRIPTION
RFC 63 proposes a standard exception handling mechanism with the syntax and
semantics of Graham Barr's Error.pm. This allows code like
try {
# fragile code
} catch Exception::IO with {
# handle IO exceptions
} catch Exception::Socket with {
# handle network exceptions
} otherwise {
# handle other exceptions
};
Exceptions are objects blessed into classes the user names after the type
of exception; their attributes include text which will be be given to
C (one that won't be trapped) if the exception is uncaught. So
modules can throw exceptions without requiring that the user be trapping them.
RFC 70 proposes that all builtins throw trappable exceptions on
error. This RFC proposes that those exceptions be objects blessed into a
standard set of classes which can be checked for by the user. This is much
cleaner than
eval {
# fragile code
};
if ($@) {
# play guessing games with regexen on $@
# and hope that the error message doesn't
# change in the next release.
}
Yes, this proposal is very Javaish. I don't do much programming in Java
but I like the way it does this.
=head2 Classes
This is a strawman exception class hierarchy. The merits of this RFC do
not depend on this beign a good hierarchy, only on it being possible to
find a reasonable one. A common prefix like C is elided for
readability.
=over 4
=item Arithmetic
Divide by zero and friends.
=item Memory
C failed, request too large, that sort of thing.
=item Eval
A compilation error occurred in C, C, or C<(?{ ... })>. Possible
candidate for subclassing.
=item Regex
A syntax error occurred in a regex (built at run-time). Possible candidate
for subclassing.
=item IO
An I/O error occurred. Almost certainly should be subclassed, perhaps
parallel to the C hierarchy.
=item Format
Error in format given to C, C, octal/hex/binary number
etc. Could use a better name.
=item Thread
Some goof in threading.
=item Object
Tried to call non-existent method, that kind of thing.
=item System
Attempt to interact with external program failed (maybe it ran out of
process slots, that kind of thing).
=item Taint
Duh.
=item Reference
Attempt to dereference wrong kind of thing.
=item Recursion
Excessive subroutine recursion, maybe also infinite C or C
loops (although arguably they would throw a C exception).
=back
There are bound to be other categories that should be covered. This is
just to put meat on the bones. This is the province of librarians and
taxonomists; the fact that it's possible to argue endlessly about the
choices doesn't preclude coming up with good ones.
=head1 IMPLEMENTATION
This should not be construed as requiring that clearly fatal errors (e.g.
pointer corrupted) should be trappable, or throw O-O exceptions. Note that
compilation errors don't have to be classified.
Do we need to mention the C<$SIG{__DIE__} problem again?
=head1 REFERENCES
RFC 63, RFC 70,
C, L.
RFC 89 (v1) Controllable Data Typing
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Controllable Data Typing
=head1 VERSION
Maintainer: Syloke Soong <[EMAIL PROTECTED]>
Mailing List: [EMAIL PROTECTED]
Date: 10 Aug 2000
Version: 1
Number: 89
=head1 ABSTRACT
Provide a choice for a programmer to define non-convertible and
semi-convertible variables with explicit data-types.
=head1 DESCRIPTION
Current intelligence and flexibility of Perl variables are extremely
indispensable. However at times this feature is also extremely
inconvenient. As an example, character string "007" is often mistaken as
int 7. So that concatenation of a variable strings "001999", "." , "03"
to form an output filename could, unless with more extensive treatment,
form a filename of 1999.3 instead. Attempts at storing into a hash with the
key "007" or " 7" rather than 7 is a trying experience. Not to mention
attempts at reading a hash using similar keys.
=head1 IMPLEMENTATION
Retain current flexibility of Perl variables.
Provide a new form of declaring variables:
my $varname type;
or
my $varname (type);
Allow the following forms to fix the data-type of a variable:
my $k int;
my $str varchar;
my $str (varchar);
my @astr (varchar);
my $ff (int,double);
my @allowedtypes = (int,varchar);
my $ivd @allowedtypes;
if ($somecondition){push @allowedtypes , double}
>From then on, evaluations on $k shall always return an integer,
unless a stringified or type-float evaluation is explicitly done on it.
$str would behave as a variable length string. $ff would behave as a
Perl5 flexible variable but constrained to either int or double.
Initially $ivd would be allowed the behave either as int or varchar.
On condition $somecondition, it is allowed an additional degree of freedom
of double due to appendage to the array @allowedtypes.
=head1 REFERENCES
RFC 92 (v1) Extensible Meta-Object Protocol -- Metho
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Extensible Meta-Object Protocol -- Method Search
=head1 VERSION
Maintainer: Tony Olekshy <[EMAIL PROTECTED]>
Date: 11 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 92
=head1 ABSTRACT
In the name of keeping Perl Perl and easy easy, Perl 6 should
maintain the current syntax and semantics for blessed objects.
Perl 6 should not I the use of an alternative meta-object
protocol, nor should it I the development of other
protocols (such as those which implement a stricter protocol).
However, Perl 6 should provide hooks into object protocol mechanisms
that would enhance the development of modules that implement other
meta-object protocols.
This RFC considers the matter of an extensible method search
protocol, which allows things like limited visibility ivars and
methods, and breadth-first multiple inheritance, to be efficiently
implemented as modules rather than as core Perl behaviour that would
be forced on all.
=head1 DESCRIPTION
Perl's current object-oriented stuff works well for certain classes
of problems. It doesn't interfere with Perl programs that don't
want to be object-oriented at all. It provides a foundation upon
which more complex object protocols can be implemented.
However, since all method names are visible in all contexts (they
are effectively "public"), it is difficult to write frameworks
containing abstract base classes that are designed to be heavily
inherited from, because internal ("private") methods can't be added
to the base classes without impacting all users of the framework.
Similar problems arise with instance variables.
At Avra we address these problems by using a module that allows us
to write publically visible framework base classes like this:
package MyClass; use Prothos::Class ISA => ParentClass;
ivar Foo => Public,Write => Private;
ivar Bar => Private, Default => "Hello, World";
ivar Baz => Protected, Default => {};
method HelloWorld => Public, sub
{
my ($I, %A) = @_;
$I->Baz(Name => $A{Name});
print $I->Baz("Name"), " says \"", $I->Bar, ",\" to $A{To}.\n";
};
method Cogitate => Private, sub
{
...
};
method OverrideMe => Protected, Bind => Virtual, sub
{
...
};
These classes play well with canonical Perl classes. Only the
behaviour of the package is affected, Perl is not globally affected.
Our module constructs objects as blessed references to an integer
which is an index into a hidden generator-scoped array of all
extant objects in the class, which means there is no way to get to
an actual object's data unless one of the (generated) methods that
can see the hidden array is used.
The ivar declarations are converted into generated method subs that
access the hidden ivar data. Ivars are internally qualified by
package name, so shadowed ivars are correctly handled.
Methods' subs are I in a hidden internal hash, and generated
subs are installed in the package namespace to fetch and invoke the
correct method closure from the hidden internal hash, using rules
that depend on the declared visiblity of the method.
This works because all the generated subs of the same name are
I, independent of package, so no matter which one is
found by Perl, the caller() context and visibility rules are used
to determine the actual closure to invoke. The generated methods
basically look like this (where $_class and $method are the names
of the class and method):
$_stash->{$method} = \&{"${_class}::$method"} = sub
{
$_ = $_cache->{$method}->{scalar caller} and goto $_;
goto \&{ &{$_stash->{_First_}}($method, @_) };
};
The run-time cost of setting all this up and doing the cache
initializations and lookups is acceptable to us. However, our
I, even with
caching, because there are two "function calls", one for the
C and one for the C.
This problem can be solved by allowing Perl's method search
mechanism to be overridden by an installed subroutine, on a
per-package basis.
=head1 IMPLEMENTATION
When Perl performs a method lookup it starts in the package of
the given object and searches up the tree of @ISA packages.
Perl should be modified so that if C<$ISA::Search> (or equivalent)
is defined for a package, then when a method is being looked up for
an object in that package, the code ref given by that value is
invoked instead of performing the default search.
The code ref should be passed the class name, method name, and the
value of C (since method visibility algorithms
typically depend on the name of the invoking context). The code ref
should be written to return the package-qualified sub name to be
invoked.
This return value should be memoized by Perl, that is, given the
same class name, method name, and C, the search code
ref should not be invoked at all. Asymptotically, this gets us back
down to one "fu
RFC 70 (v2) Allow exception-based error-reporting.
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Allow exception-based error-reporting. =head1 VERSION Maintainer: Bennett Todd <[EMAIL PROTECTED]> Date: 8 Aug 2000 Last-Modified: 12 Aug 2000 Version: 2 Mailing List: [EMAIL PROTECTED] Number: 70 =head1 ABSTRACT Allow full implementation of Fatal.pm, for programmers who prefer exceptions for error reporting. =head1 DESCRIPTION Perl has traditionally reflected the Unix syscall and library tradition for error reporting: errors are indicated by otherwise-impossible return values, which must be checked for explicitly, lest system error events be ignored. Some programmers prefer to have errors print a message and exit with non-zero status, by default, rather than having to always code " || die ...". In perl5 this has proven elusive of implementation. Fatal.pm has been the attempt made to date, and it suffers from two problems. One can be fixed with further development: it should have various lists of builtins available, e.g. :io, :system, :all for including all calls affecting I/O, all system calls of any sort, and all calls that can have error returns. If these were a success, then the requested category could also be posted into a testable variable, allowing module authors who wished to to automatically support this functionality as well. But Fatal.pm development stalls out early, because some builtins, which report testable error conditions, cannot be wrapped. A conspicuous example is print(). =head1 IMPLEMENTATION Ensure that every perl builtin that can return an error, can be wrapped. I don't know whether this is purely an implementation issue (and so lies solely in the domain of perl6-internals) or whether any programmer-visible changes may be necessary to allow this (justifying posting to perl6-language). =head1 REFERENCES Fatal.pm, as included with recent perls. Error.pm, available from CPAN, and cited by RFC 63: if this proposal should carry, then Fatal.pm will see some very active development, and if RFC 63 should also prevail, then Fatal's development should be guided by RFC 63/Error.pm. RFC 80 Proposes a taxonomy for exception objects; should it prevail, it should guide the structure of exceptions thrown when Fatal.pm gets worked on.
RFC 89 (v2) Controllable Data Typing
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Controllable Data Typing =head1 VERSION Maintainer: Syloke Soong <[EMAIL PROTECTED]> Mailing List: [EMAIL PROTECTED] Date: 10 Aug 2000 Last-Modified: 12 Aug 2000 Version: 2 Number: 89 =head1 ABSTRACT Provide a choice for a programmer to define non-convertible and semi-convertible variables with explicit data-types. =head1 DESCRIPTION Current intelligence and flexibility of Perl variables are extremely indispensable. However at times this feature is also extremely inconvenient. As an example, character string "007" is often mistaken as int 7. So that concatenation of a variable strings "001999", "." , "03" to form an output filename could, unless with more extensive treatment, form a filename of 1999.3 instead. Attempts at storing into a hash with the key "007" or " 7" rather than 7 is a trying experience. Not to mention attempts at reading a hash using similar keys. A compromise between dead-bolted types and liberal types is struck through constrained and controllable typing. There is a hint of polymorphic behaviour. =head1 IMPLEMENTATION Retain current flexibility of Perl liberal variables. Provide a new form of declaring variables: scope cast-type $varname:constraint; Valid declarations would be: my $varname; my (var-list); my cast-type $varname; my cast-type (var-list); my $varname:constraint; my (var-list):constraint; my cast-type $varname:constraint; my cast-type (var-list):constraint; my $varname:(constraint-list); my (var-list):(constraint-list); my cast-type $varname:(constraint-list); my cast-type (var-list):(constraint-list); =head2 Simple examples my $old; my int $k; my varchar $str; my char(5) $zip; use CGI; my CGI $q; my Net::SNPP ($pg, $pq); my int $a = 3.9; my int $ceil = 3.9 + 0.5; my int $i = 'hello'; my double $f1 = 'hello'; my double $f2 = $a; $old is the declaration of a liberal type; $a evaluates to int 3; $ceil evaluates to int 4; $i evaluates to int 0; $f1 evaluates to double 0.; $f2 evaluates to double 4.; =head2 Constant constraint A constant confered by the keyword const creates a final value; That value stays immutably the same throughout the scope of its existence. my $a1:const; my int $k1:const; my varchar $str1:const; my $a21:const = '023'; my $a22 = 3 + $a21; my $a23 = 3.$a21; my int $k21:const = '023'; my int $k22:const = 23; my varchar $str21:const = 3; my char $str22:const = 3; my char(1) $str22:const = 3; my Net::SNPP ($pg, $pq):const; my Net::SNPP ($pr, $ps):const = new Net::SNPP ; my Net::SNPP ($pt = $pu, $pv):const = new Net::SNPP ; use strict(constcroak); $str22 = 'hello'; $a1, $k1, $str1 are henceforth constantly null liberal, int and varchar respectively; $$a21 acquires constant value of char(3) '023'; $a22 acquires variable value of liberal-type 26; $a22 acquires variable value of liberal-type 3023; $k21, $k22 both acquire constant values of int 23; $str21, $str22, $str23 all acquire variable values of char(1) 3; $pg and $pq henceforth vainly reference null objects of Net::SNPP; Whereas $pr, $ps, $pv usefully and loyally reference separate objects of Net::SNPP; $pt and $pu both reference the same Net::SNPP object constantly. The strict directive, default being noconst (disregard any harassment on a const), is set to croak when an attempt to change the value of constant $str22 is made. Use of use strict(constdie); should also be an option. =head2 Constraint lists my $id:(double,int); my int $id1:(double,int) = 1.7; my int $id2:(varchar, double) = 2.6; my int $id3:(varchar, double, int) = 2.6; my char $c1 = 'a'; my char $c2:char = 'a'; my char $c3:(char) = 'a'; my $id4:(varchar, double, int) = 2.7; my $id5:(varchar, double, int) = 3; my $id6:(varchar, double, int) = 'Fatrick Perlland'; $id is constrained to behave either as double or int; $id1 is constrained to behave either as double or int, but int casting initialises it to (double,int) 1; $id2 and $id3 are similar declarations such that a cast not found in the constraint list will be spontaneously added to the constraint list; Both acquires (varchar, double) value of 2.6; Declarations of $c1, $c2, $c3 are all equivalent forms. Declaration of $c1 follows the rule of spontaneous appending a cast to its constraint list. $id4, $id5, $id6 are constrained to behave either as varchar, double or int; $id4 acquires value of (varchar, double, int) 2.7; $id5 acquires value of (varchar, double, int) 3; $id6 acquires value of (varchar, double, int) '
RFC 101 (v1) Handlers and Pseudo-classes
ss is imported, it should be able to automatically register as
a member of a certain C. For example, the above code would be
better written as:
use MyHTTP;# these register as 'http'
use LWP::UserAgent;# handlers automatically
$fo = open http "http://www.yahoo.com";
This means that there needs to be some mechanism for a module to execute
the equivalent of a 'use handler' statement, but have it take affect in
the package C.
=head2 Handler Deregistration
In addition to handlers being added, they need to be removed as well.
This is where C comes in:
no handler 'http' => 'MyHTTP'; # remove MyHTTP from list
no handler 'http'; # remove http handler
The first example removes C from the list of classes used by the
C handler. The second syntax removes the C handler entirely,
meaning that this call:
$fo = open http "http://www.yahoo.com";
will result in the familiar error:
Can't locate object method "open" via package "http"
This should obey blocks as well (like C), allowing you to say:
{
# force LWP::UserAgent to be used
no handler 'http' => 'MyHTTP';
$fo = open http "http://www.yahoo.com";
}
$fo2 = open http "https://www.etrade.com";
=head1 IMPLEMENTATION
We'll get to this later. This RFC is probably going to be revised a lot.
=head1 REFERENCES
RFC 14: Modify open() to support FileObjects and Extensibility
RFC 8: The AUTOLOAD subroutine should be able to decline a request
http://www.mail-archive.com/perl6-language-io@perl.org/msg00086.html
RFC 102 (v1) Inline Comments for Perl.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Inline Comments for Perl.
=head1 VERSION
Maintainer: Glenn Linderman <[EMAIL PROTECTED]>
Date: 14 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 102
=head1 ABSTRACT
Unlike many programming languages Perl does not currently implement
inline comments. This can be confusing/tedious to programmers. This
could be solved by adding a syntax to Perl 6 that would allow for inline
comments.
=head1 DESCRIPTION
Comments are important to programmers as a way of documenting their code
and for debugging purposes. Perl's comment syntax requires that
comments can only be placed at the end of a line, or on a separate line
(or lines). Sometimes it is desirable to place a comment (or comments)
within a line.
Perl currently uses the "#" character as an end-of-line comment
introducer (as do many other scripting languages). RFC 5 (multiline
comments) suggests as a possible promising syntax an introducer of the
form "#<#". I like this one best,
of the three paired character possibilities ("<>", "()", "{}") because
it is more closely related to the "#<# comment
from appearing, this suggestion is not 100% compatible with perl5
syntax. However, such a sequence is relatively unlikely: I've never
seen one in any Perl code I've perused. By limiting this construct
to less than a single line, it limits the boundaries of confusion:
if "#<" is found with the intended meaning of an end-of-line
comment introducer followed by a "<" character, the highly probable
lack of the sequence ">#" within the same line can be diagnosed with
a warning or error identifying exactly the line involved.
=head2 Discussion in perl6-language and perl6-language-mlc
There was some discussion of in-line comments in the
perl6-language and perl6-language-mlc lists. There wasn't a
consensus reached. The competing suggestion for in-line comments was
to define "qc/comment/" as a syntax that evaporates. I don't like
that syntax, because it looks more like code than comment, and doesn't
stand out to the eye as a comment when mixed within code:
$foo = qw/foo bar/ qc/eat me/;
It is not clear whether such syntax would be easily readable within all
forms of expressions, without operators, as shown in the above example,
vs
$foo = qw/foo bar/ ##;
=head1 IMPLEMENTATION
Should be straightforward in the Perl parser/lexer.
=head1 REFERENCES
RFC 5 (multiline comments) see http://dev.perl.org/rfc
Discussion archives of the perl-language and perl-language-mlc lists
RFC 103 (v1) Fix print "$r->func" and $pkg::$var precedence
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Fix print "$r->func" and $pkg::$var precedence
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 14 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 103
Status: Developing
=head1 ABSTRACT
Currently, attempting to use objects in a string context
yields garbage:
print "r is $r->func"; # "OBJ=HASH(0xef958)->func"
print "r is ", $r->func; # works, but clumsy
In addition, trying to dynamically assign to unnamed classes
is very difficult:
$pkg::$var = $val; # error
${"${pkg}::$var"} = $val; # works, but bleeech!
The precedence and parsing of these operators should be fixed to allow
these important operations.
=head1 DESCRIPTION
=head2 Printable objects
This should print out correctly:
$r = new Class;
print "$r->func";
This would make it consistent with hashrefs and arrayrefs, which already
work correctly in string contexts.
Note that both this RFC and RFC 49 propose changes that make an object's
debugging info hard to get to. The next version of RFC 49 will include
an operator for easily accessing that information. Please see it for
details.
=head2 Dynamic package names
Currently, assigning values to dynamically-created package names is,
frankly, and pain in the butt. Major. These should work in Perl 6:
$pkg = 'Class';
$var = 'DEBUG';
$pkg::$var = 1;
$subpkg = 'Special';
$class = $pkg . '::' . $subpkg;
require $class; # require Class::Special
Currently, the precedenence of :: vs. symbolic references does not allow
these operations.
=head1 IMPLEMENTATION
I'll leave that to the internals guys. :-)
=head1 REFERENCES
RFC 49: Objects should have builtin stringifying STRING method
Programming Perl, 2ed, for the ${"${pkg}::$var"} syntax
RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Maintain internal time in Modified Julian (not epoch) =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 14 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 99 Status: Developing =head1 ABSTRACT Currently, internal time in Perl is maintained via C, in seconds since the UNIX epoch (01 Jan 1970 UTC). However, this is a very ancient approach and quite UNIX-centric. Perl 6 should maintain its internal clock source as the Modified Julian Date. =head1 DESCRIPTION The Modified Julian Date is a system-independent, universally recognized time source. It has several key advantages builtin, including: 1. The ability to do date arithmetic with simple math ops 2. It can be used to easily derive many other sources, including UTC and local time 3. It is platform and even computer-independent This RFC proposes several key changes to Perl 6's internal time- keeping: 1. Maintain time internally via Modified Julian Date (MJD) 2. Replace C with C, which will return MJD 3. Make all core time and date functions based off MJD =head1 IMPLEMENTATION The C core function should be moved to an external module, such as C or C. A core C function should be added, which returns the Modified Julian Date. Its name was chosen to make it consistent with the new C and C functions described in RFC 48. =head1 REFERENCES RFC 48: Replace localtime() and gmtime() with date() and utcdate() Tim Jenness and Buddha Buck for their great links: http://www.jach.hawaii.edu/JACpublic/stardocs/sun67.htx/node217.html http://tycho.usno.navy.mil/systime.html http://tycho.usno.navy.mil/mjd.html
RFC 108 (v2) Scope of Polymorphic References and Objects
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Scope of Polymorphic References and Objects
=head1 VERSION
Maintainer: Syloke Soong <[EMAIL PROTECTED]>
Mailing List: [EMAIL PROTECTED]
Date: 15 Aug 2000
Last-Modified: 16 Aug 2000
Version: 2
Number: 108
=head1 ABSTRACT
Syntax for Polymorping and Scoping References
=head1 DESCRIPTION
This is a proposal to define the scoping and overloading of Perl
references. The polymorphic signature is proposed to comprise the arglist
members, candidate operators and the return list members. In other words,
rather than the tradition of using just the head (java) or head+operator
(c++), the proposal is for head+tail or head+operator+tail polymorphic
signatures .
=head1 IMPLEMENTATION
Reference to RFC89 is recommended to relate to fixating or constraining
the data type of a variable.
For comprehension of this proposal, the following terms are held within
the bounds of this document. The concept stays, notwithstanding.
var $a;
our $b;
my $c;
$d = 0;
$a is defined to be referentiable as public.
$b is defined to be referenced within protected bounds of a package .
$c is defined to be referentiable only privately within a function.
$d is defined implicitly to be referentiable privately within a file.
=head2 A new object module declaration method
Allow function arg list but continue to use @_;
The following would be equivalent forms in Perl5 and Perl6, respectively:
package Pine::Tree::State;
sub genesis
{
my ($pkg, $oak, $maple) = @_;
my $a = {};
bless $a, $pkg;
return $a;
}
package Pine::Tree::State;
var genesis:(\new);
function new ($oak :int, $maple: double)
{
bless $a:const={}, genesis;
our $world={};
return $a;
}
function aux ($spruce:int)
{
my $world = this->$world; # this is instance handle of self object
# my $world = our->$world; # how about using our?
# my $world = my->$world; # or what about my?
}
=head2 Overloading of references
A reference may be overloaded with a search list, thus acting as a container.
my $a1:(int) = 3;
my $a2 = 4;
my $a3:(int);
my $a:($a1, $a2, $a3, double);
$a is constrained in the following precedence
- references $a1 if an integer evaluation is done
- references $a2 if a liberal evaluation is done
- references double if a double evaluation is done
- $a3 is unreachable because $a1 is precedent in the search list
$a = 11; #equivalent to $a1 = 11;
$b:(int) = $a ; #equivalent to int $b = $a1;
$a = 11.1; $c:(double) = $a ; #equivalent to double $c = 11.1;
$a = 11.1; $c:(varchar) = $a ; #equivalent to varchar $c = '11.1';
$a = 11.9; $d:(int) = $a ; #equivalent to int $c = 11;
$a = 11.9 + 0.5 ; $ceiling:(int) = $a ; #equivalent to int $ceiling = 12;
=head2 Overloading of object containers
package Pine::Tree::State;
var genesis:(\new_a, \new_b, \new_c);
var habakuk:(\new_b, \new_c);
var getab:(\new_a, \new_b);
function new_a ($oak int, $maple double)
{
return bless $a:const={}, genesis;
}
function new_b ($oak:(varchar,int), $maple)
{
bless $a={},genesis;
bless $b={},habakuk;
my $c={};
var $r:($a,$b,$c);
return $r;
}
function new_c (varchar $oak, $maple, $pine)
{
bless $a:const={}, (genesis,habakuk);
return $a
}
#!/usr/bin/perl
use Pine::Tree::State;
my $a:(varchar,int);
my habakuk $pineapple = genesis Pine::Tree::State($a, 'Banana');
my $melon = genesis Pine::Tree::State($a, 'Banana');
Blessing genesis confers it a constructor container. genesis is overloaded with
two function references stored in an array. Refer to RFC89 for fixating the
data type of a variable. getab is an overloaded function container but not of
constructors. new_c acts as a constructor through genesis or habakuk but not
through getab.
Matching a call to a member of a container is by means of a signature due to
the combination of the function argument list and return list. RFC89
suitability and precendent rules apply to matching signatures. The order of the
array dictates the search order to match a call to the members of an overloaded
reference.
habakuk is an alternate constructor within the package.
new_b is an insteresting constructor/function. Can you theorise what happens
when new_b is activated through constructor container genesis, or constructor
container habakuk, or object container getab?
Notice new_b has arglist member $oak:(varchar,int), while new_c has varchar
$oak. Effects of type casting and contraint are propagated into the function
body.
Signature of new_b is invoked by the genesis of Pine::Tree::State by
$pineapple. $new_b->$r is an overloaded reference. Return of $r is a
polymorphic return. $pineapple invokes new_b through genesis but has a casted
reception for habakuk. So even though it is genesis'ed it becomes a habakuk
object. Meanwhile $melon becomes
RFC 113 (v1) Better constants and constant folding
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Better constants and constant folding
=head1 VERSION
Maintainer: John Siracusa <[EMAIL PROTECTED]>
Date: Aug 15 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 113
=head1 ABSTRACT
There are many ways to use named "constants" in Perl, but they all have
drawbacks: runtime initialization costs, the extra overhead of loading
another module, the inability to use the constants in certain situations,
and so on.
Constants should be first-class citizens in Perl, and should be constant
folded with a vengeance by a clever compiler.
=head1 DESCRIPTION
An ideal Perl constant can be used anywhere that a Perl variable of the
same type can be used: a constant scalar can be used in place of any
scalar, a constant array can be used in place of any array, and so on.
These constants should not incur runtime inefficiencies or undue
compile-time overhead. Performance should be should be exactly as if the
data was hard-coded in place.
=head1 IMPLEMENTATION
The simplest solution is something like:
constant $PI = 3.14159265;
This looks shockingly similar to the current, much maligned (by me, anyway)
constant module:
use constant PI => 3.14159265;
but the former has many syntactic advantages. First, there's no "use"
directive to reveal the constant's second-class citizenship. Second, it
uses the assignment operator instead of the "fancy comma." Third, context
is determined by the left-hand-side of the assignment operator instead of
always being forced into list context.
Using these constants is simple. They behave just like variables of the
same type.
print "Would you like some apple $PI?"; # A constant string
That whole string is converted to a single constant at compile time.
Collections behave in a similar manner:
constant @FISH = (1, 2, 'red', 'blue');
print @FISH; # prints "12redblue"
print "@FISH"; # prints "1 2 red blue"
print "$FISH[2] head"; # prints "red head"
Again, each argument to C is converted to a constant string at
compile time.
Modification of a constant is a compile-time error:
$PI = 5; # Bzzt!
$PI =~ s/\.\d+$//; # Sorry
$#FISH = 15; # Nice try
The C keyword should work when combined with C and C:
package Foo;
our constant $GOO = 5;
if(...)
{
my constant $GOO = 10;
print $GOO; # Prints 10
}
As an added implementation bonus, "constant methods" should be supported
in the same way that "constant subroutines are now.
package MyConstants;
constant $PI = 3.14159265;
package MyClass;
...
sub method { $MyConstants::PI }
package MyLib;
...
sub func { $MyConstants::PI } # Shouldn't have to be sub func() ...
Both C and C should know that they return constants,
and the compiler should optimize them away whenever possible, even without
explicit hints like an empty "()" prototype after C. Yes, there
are issues with turning a method call into a constant at compile time, but
it's possible if Perl can determine with certainty that C
is the actual code that will be executed by an object or class method call.
Example:
my $obj = MyClass->new;
print $obj->method();# Converted to the constant 3.14159265
print MyClass->method(); # Ditto
Again, this magic is accomplished by a clever compiler that does not need
this type of help:
my MyClass $obj = MyClass->new; # Not necessary, ideally
As should be clear by now, I'm not too familiar with the perl internals
that are required to support this stuff. It just "seems possible" to me.
And hey, there are no "perl internals" to speak of yet in a "clean-sheet"
implementation, right?
=head1 REFERENCES
Perl's C pragma documentation.
RFC 114 (v1) Perl resource configuration
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Perl resource configuration =head1 VERSION Maintainer: Jonthan Scott Duff <[EMAIL PROTECTED]> Date: 16 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 114 =head1 ABSTRACT Perl should provide a mechanism to have common code autoloaded from a file. =head1 DESCRIPTION Many other programs have so called "resource configuration" files (at least that's what I call them) that are loaded and interpretted upon program startup. Some example programs that have this ability include bash, mutt, and python. Perl should do the same. A C file could be used to set system-wide defaults that the system administrator would like to promote. For instance, C could turn on stricture or warnings. This RFC proposes that Perl 6 support 2 "rc" files: a per-user file located in the user's home directory C<~/.perlrc> and a global "rc" file, C, that affects all instances of perl running on the machine. Note that this is couched in terms of a Unix-ish filesystem. Perl should support the analogous concept for the other platforms on which it compiles. =head1 IMPLEMENTATION Make perl look for the rc files. =head1 REFERENCES Perl 5.6.0 Documentation python documentation bash documentation mutt documentation
RFC 115 (v1) Default methods for objects
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Default methods for objects
=head1 VERSION
Maintainer: pdl-porters team <[EMAIL PROTECTED]>
Date: 16 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 115
=head1 ABSTRACT
This RFC proposes syntactic support for default methods
that can be defined for blessed references. This would
allow the brackets C<()>, C<{}> and C<[]> to be used
for a variety of convenient syntaxes for objects and
allow abolition of tie's.
=head1 DESCRIPTION
=head2 Motivation
Currently, PDL objects have to use quite an unwieldy syntax
for the all important slicing and indexing. In perl5 the syntax is
$n1 = $n-1; # since we need to stringify
$y = $x->slice("0:$n1:4");
This should be contrasted with the less cluttered syntax offered
by numerical Python and commercial systems such as Matlab and IDL:
y = x[0:n-1:4];
In perl we desire to say:
$y = $x[0:$n-1,4];
or even
@y = @x[0:$n-1,4];
If there is a more general unification of PDL arrays and normal
perl arrays. (See L).
Note that we need to keep l-value subs in perl6 to avoid related
types of syntactical clumsiness if C<$x[]> can invoke a subroutine
(see below).
$x[0:$n-1:4] *= 2;
should be allowed, as well as the long form
$x->slice(0:$n-1:4) *= 2;
Also it is important to be able to do multi-dimensional lookups
efficiently with compact arrays:
$y = $x[1:10,5:99];
L proposes introducing ranges as part of the
syntax cleanup, this RFC proposes default methods for
objects.
=head2 Default methods
If classes allowed the definition of a default method that
is invoked with a syntax akin to one used with sub refs we
could have the cake and eat it. The default method notion
seems general enough to be useful for other classes. If normal
perl arrays become able to be represented by objects then one might wish
to say C<@x[0:$n-1,4]>
=head2 Examples:
A possible scenario could be as follows. The class PDL
defines a default method that is invoked when a syntax
like
$[args]
is used, where C<$Evariable_nameE> is supposed to be an
instance of the class in question (here PDL).
The PDL package would contain the definition of the
method C and C:
package PDL;
sub DEFAULT_SQUARE_FETCH {
my $this = shift;
$this->slice(@_);
}
# In this case store/fetch are the same.
*DEFAULT_SQUARE_STORE = \&DEFAULT_SQUARE_STORE;
In a more complex case (for example an array object tied to a
database) the FETCH/STORE methods would be different code.
Similar methods would be provided for C<{}> and C<()>. This
would allow for the creation of a variety of powerful syntaxes
for different kinds of objects. For example in PDL we might
wish to use C<[]> to slice by index value and C<{}> to slice
by physical real-value coordinate.
All this would probably make implementation of tied classes
a lot more straight forward and makes the tieing mechanism
more closely unified with the object mechanism. The current
tie mechanism is unwieldy and inelegant.
One could also think of this as saying C<()>, C<{}> and C<[]>
are operators which can be overloaded.
=head1 IMPLEMENTATION
Changes to the parser to allow the new syntax. Other issues?
Maybe all 3 of these are unnecessary - but at least 2 would
be darn useful.
=head1 REFERENCES
RFC 117: Perl syntax support for ranges
L (http://pdl.sourceforge.net/PDLdocs)
http://pdl.perl.org
Numerical Python:
http://starship.python.net/~da/numtut/
RFC 117 (v1) Perl syntax support for ranges
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl syntax support for ranges
=head1 VERSION
Maintainer: pdl-porters team <[EMAIL PROTECTED]>
Date: 16 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 117
=head1 ABSTRACT
This RFC proposes syntactic support for ranges. Range objects
would be especially useful to specify indexing ranges of compact
numerical arrays (currently implemented by PDL) in a concise
manner, e.g.
$y = $x->slice(0:$n-1:4);
Note that currently (perl5) we have to say
$n1 = $n-1; # since we need to stringify
$y = $x->slice("0:$n1:4");
This should be contrasted with the less cluttered syntax offered
by numerical Python and commercial systems such as Matlab and IDL:
y = x[0:n-1:4];
In perl we desire to say:
$y = $x[0:$n-1,4];
or even
@y = @x[0:$n-1,4];
If there is a more general unification of PDL arrays and normal
perl arrays. (See L).
This RFC proposes ranges as part of the syntax cleanup,
L proposes a default method for objects. This RFC is
closely linked to RFC 81: C
(and proposes a subset of the features of that RFC) but emphasizes
two additional aspects: Motivation by requirements of
PDL and the important implementation aspect of I.
=head1 DESCRIPTION
A range would be an object that is different from current perl5
lists but could be interpolated into one if desired. The C<:> operator
would be the range generating operator.
The behaviour would be similar to the '..' operator but generally
no explicit in-memory list would be generated. These ranges would be
very useful to concisely specify subslices into multi-dimensional
numerical arrays.
Perhaps the '..' operator can be recycled as
something else and ':' used for all ranges (or ':' simply be an alias
for '..').
=head2 Examples:
: # all the things on this dimension: full span
5:-1# 5..last
5:-1:2 # Every second item, up to the last or second last
-1:7:3 # Start with last item, then fourth last, etc. until 7
for (0:7) { ... }
for (0.1:1.0:0.1) { ... }
$pdl->slice(-1:$n:3) .= 5;
$pdl->slice(:,::2) *= 2;
An issue is the treatment of potentially infinite ranges of the form
:
:5
and similar cases. Those could raise an error if used in a context
where actual list items are generated, e.g.
for (:) { $a *= $_ }
but be allowed in circumstances where no explicit list item is
ever created, e.g.
$a->slice(:)
which might actually be written in perl6 as
$a[:]
=head1 IMPLEMENTATION
Possible. A range should probably be a lazily evaluated list which
functions can choose to accept without the need to actually generate
the list in memory. Compare the RFC on lazy list generation.
A detail that is crucial from our point of view that is not mentioned
in RFC 81 is the ability for a function to inquire the C
parameters of the range and do its own thing without ever generating
a list or list iterator -- an implementation aspect we refer to as
I.
=head1 REFERENCES
L (http://pdl.sourceforge.net/PDLdocs)
http://pdl.perl.org
RFC 24: Semi-finite (lazy) lists
RFC 81: Lazily evaluated list generation functions
RFC 104 (v1) Backtracking
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Backtracking
=head1 VERSION
Maintainer: iVAN Georgiev <[EMAIL PROTECTED]>
Date: 14 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 104
=head1 ABSTRACT
Backtraking mechanism is core functionality of languages like PROLOG.
Perl-regex engine has this ability too.
Adding this mechanism to our programming arsenal will bring alot of
new functionality. Will help us solve problems that otherwise cost us
alot of time and effort (laziness).
A new paradigm to Perl - DECLARATIVE programming.
=head1 DESCRIPTION
The whole gang-bang can be done with only two new operators: andthen, orthen.
They behave similarly like &&, ||, and, or operator with one main
distinction they "backtrack" for example:
{ block1 } B { block2 };
mean this:
if "block1" return true(1) "block2" is evaluated then
if "block2" return true(1) the end result is true(1)
if "block2" return false(0)
we evaluate "block1" again i.e start from the beginning.
but if "block1" return false(0) the end result is false(0)
or to be more clear this is the Perl equivalent/example:
my $res = 0;
{
my $ex1;
{ $l = (rand() > 0.3) ? 1:0;print "block1=$l\n"; $ex1=$l};
if ($ex1)
{
my $ex2;
{ $r = (rand() > 0.7) ? 1:0;print "block2=$r\n"; $ex2=$r};
if ($ex2) { $res = 1 } else { redo }
};
};
print "The result is : $res\n";
Similarly "orthen":
{ block1 } B { block2 };
mean this:
if "block1" return true(1) the end result is true(1)
but if "block1" return false(0) "block2" is evaluated then
if "block2" return true(1) the end result is true(1)
if "block2" return false(0)
we evaluate "block1" again i.e start from the beginning.
OR this:
if "block1" return true(1)
we evaluate "block2" and return true(1)
w/o taking in consideration the result of "block2" evaluation.
but if "block1" return false(0) "block2" is evaluated then
if "block2" return true(1) the end result is true(1)
if "block2" return false(0)
we evaluate "block1" again i.e start from the beginning.
=head2 USAGE
Good candidates for "backtracking" are XML processors,
analytical "permutations!", expert systems and many more...
Cycle:
my $i = 0;
{$i++; $i <= 10 } andthen {print $i};
equivalent to:
for (my $i=1;$i++;$i<=10) {print $i};
=head2 FURTHER WORK
As you saw I tried to propose as small change to the perl
core/language as possible, which can be easily implemented.
What else we can expect?
One good addition that can we thought about is implementing
the Perl BLOCK's as forth-state BLACKBOX structure not as
it is now i.e. two states, what I mean ?
Currently AFAIK we have "entering" and "leaving" the block.
We can have "direction" i.e. with "backtrack" mechanism we
can enter the block from previous block or from the next one -
the four "states" are - enter(->),leave(->),reevaluate(<-),fall(<-),
we will need also to count how many times the block has been
in all of these states. We can leave the old behaviour as
default(in the name of speed) and only when the Perl programmer
need these states to use "state" pragma.
use state "2";
use state "4";
BUT this will be alot of work, so for now andthen, orthen
are enough. If backtracking is made as more general algorithm
it can be used both by Perl itself and regex engine ?!!
=head1 IMPLEMENTATION
There is many possible implementations one of them you saw
in DESCRIPTION section, it can also be implemented as
while, until cycle...
If I was perl-core hacker you now will be reading
and applying the patch :"), I believe that this can be very
easily implemented as just adding several lines in perly.y
(please excuse my ignorance if this is not the case)
=head1 REFERENCES
perldoc perlre
The Prolog Language:
http://www.sics.se/SICS-reports/SICS-T--93-01--SE/report_10.html
Coroutining facilities:
http://www.sics.se/SICS-reports/SICS-T--93-01--SE/report_8.html
RFC 110 (v1) counting matches
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE counting matches =head1 VERSION Maintainer: Richard Proctor <[EMAIL PROTECTED]> Date: 16 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 110 =head1 ABSTRACT Provide a simple way of giving a count of matches of a pattern. =head1 DESCRIPTION Have you ever wanted to count the number of matches of a patten? s///g returns the number of matches it finds. m//g just returns 1 for matching. Counts can be made using s//$&/g but this is wastefull, or by putting some counting loop round a m//g. But this all seams rather messy. m//gt would be defined to do the match, and return the count of matches, this leaves all existing uses consistent and unaffected. /t is suggested for "counT", as /c is already taken. Using /t without /g would be result in only 0 or 1 being returned, which is nearly the existing syntax. (Note I am only on the announce list at present as I am suffering from negative free time). =head1 IMPLENTATION No idea =head1 REFERENCES I brought this up on p5p a couple of years ago, but it was lost in the noise...
RFC 111 (v1) Whitespace and Here Docs
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Whitespace and Here Docs =head1 VERSION Maintainer: Richard Proctor <[EMAIL PROTECTED]> Date: 16 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 111 =head1 ABSTRACT With a here doc print <
RFC 112 (v1) Assignment within a regex
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Assignment within a regex
=head1 VERSION
Maintainer: Richard Proctor <[EMAIL PROTECTED]>
Date: 16 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 112
=head1 ABSTRACT
Provide a simple way of naming and picking out information from a regex
without having to count the brackets.
=head1 DESCRIPTION
If a regex is complex, counting the bracketed sub-expressions to find the
ones you wish to pick out can be messy. It is also prone to maintainability
problems if and when you wish to add to the expression. Using (?:) can be
used to surpress picking up brackets, it helps, but it still gets "complex".
I would sometimes rather just pickout the bits I want within the regex itself.
Suggested syntax: (?$foo= ... ) would assign the string that is matched by
the patten ... to $foo when the patten matches. These assignments would be
made left to right after the match has succeded but before processing a
replacement or other results. There may be whitespace between the $foo and
the "=". This would not give the backrefs \1 etc that come with conventional
bracketed sub expressions, I don't think this would be a problem.
Potentially the $foo could be any scalar LHS, as in (?$foo{$bar}= ... )!,
likewise the '=' could be any asignment operator.
The camel and the docs include this example:
if (/Time: (..):(..):(..)/) {
$hours = $1;
$minutes = $2;
$seconds = $3;
}
This then becomes:
/Time: (?$hours=..):(?$minutes=..):(?$seconds=..)/
This is more maintainable than counting the brackets and easier to understand
for a complex regex. And one does not have to worry about the scope of $1 etc.
(Note I am only on the announce list at present as I am suffering
from negative free time).
=head1 IMPLENTATION
No idea
=head1 REFERENCES
I brought this up on p5p a couple of years ago, but it was lost in the noise...
RFC 29 (v2) unlink() should be left alone
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE unlink() should be left alone =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 04 Aug 2000 Last-Modified: 14 Aug 2000 Version: 2 Mailing List: [EMAIL PROTECTED] Number: 29 Status: Frozen =head1 STATUS This RFC was discussed on perl6-language-unlink with no objections. It has been frozen in its current format. =head1 ABSTRACT Some people have suggested that unlink() is too Unix centric, that that it should be renamed to something like delete() or remove(). This should not happen. unlink() should remain unlink(). =head1 DESCRIPTION While on the surface, renaming unlink() may seem like a not-too-bad-idea, in reality it has many bad parts: 1. It confuses experienced Perl, C, and Unix programmers 2. It makes link() and symlink() almost non-sensical 3. It's possible to have more than one link to a file in Unix, meaning unlink() != delete(). 4. It's a useless change. It's not broken. Renaming a function just for the sake of renaming a function, when in reality it works identically to the native C counterpart, does not add value to Perl 6. =head1 IMPLEMENTATION Nothing to be done! For those that are adamant about this, I suggest that they consider writing a module, say "Win32::Synonyms", that could be composed of typeglobs: *delete = \&CORE::unlink; With better referencing in Perl 6 this should be easily possible. However, I think it's RABID (Really A Bad IDea) at best. =head1 REFERENCES RFC 28: Perl should stay Perl, by Simon Cozens Unix unlink(2) man page
RFC 105 (v1) Downgrade or remove "In string @ must be \@" error
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Downgrade or remove "In string @ must be \@" error =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 15 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 105 Status: Developing =head1 ABSTRACT Currently, if you write: $email = "[EMAIL PROTECTED]"; You get a B error: In string, @wiger now must be written as \@wiger This should be a warning or removed altogether in Perl 6. =head1 DESCRIPTION This is something that was put in to catch Perl 4 to Perl 5 migration. Perl 6 shouldn't need it, and should just assume that "@wiger" is an array, even if it's unitialized. This is what it does for all the other data types. Either that, or catch all the unused occurrences of %, $, @, and so on. For example, neither of these creates a fatal error (or even a warning): $email = "nate$wiger.org"; $email = "nate%wiger.org"; =head1 IMPLEMENTATION Downgrade the error to a warning. Even better, remove the warning altogether. Perl 5's been out for years. =head1 REFERENCES http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-07/msg02150.html
