Re: RFC 272 (v1) Arrays: transpose()
[EMAIL PROTECTED] wrote: Jeremy Howard wrote: So where is mv(), you ask? If you use the 'reorder' syntax, but don't specify all of the dimensions in the list ref, then the remaining dimensions are added in order: That sounds good. I'd say why not also allow the mv syntax? It is syntactically different from the others, may be the least often used variant but then there are N+1 ways to do it ;) But no strong feelings either way... It might be best avoided, because it's weird to see hash refs used as parameters to builtins in this way. I'll tell you what... I'll add it in as an 'optional extra'. That way people who don't like it can't use it as an excuse to belittle the whole proposal...
RFC 272 (v2) Arrays: transpose()
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Arrays: transpose()
=head1 VERSION
Maintainer: Jeremy Howard [EMAIL PROTECTED]
Date: 22 Sep 2000
Last Modified: 24 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 272
Version: 2
Status: Frozen
=head1 DISCUSSION
This RFC was modified to incorporate the functionality of PDL's xchg() and
mv(), which are useful for acting on arbitrary dimensions of
multidimensional arrays. Implementing aliasing was discussed in more
detail than for RFCs 90, 91, and 148, including suggestions to learn from
PDL's implementation (outlined in RFC 116), which are more sophisticated
than simply keeping a list of mapped indices, instead actually storing
information about the specific operations that have occured.
=head1 ABSTRACT
It is proposed that a new function Ctranspose be added to Perl.
Ctranspose($dim1, $dim2, @list) would return @list with $dim1 and $dim2
switched. Ctranspose(\@order, @list) would return @list with dimensions
in the order specified by @order. Ctranspose would return an alias into
the original list, not a copy of the elements.
=head1 DESCRIPTION
=head2 Swapping Dimensions
It is proposed that Perl implement a function called Ctranspose that
transposes two dimensions of an array, and is evaluated lazily. LRFC 202
gives an overview of the proposed multidimensional arrays that
Ctranspose works with. For instance:
@a = ([1,2],[3,4],[5,6]);
@transposed_list = transpose(0,1,@a); # ([1,3,5],[2,4,6])
This is different to Creshape (see LRFC 148) which does not reorder
its elements:
@a = ([1,2],[3,4],[5,6]);
@reshaped_list = reshape([3,2],@a); # ([1,2,3],[4,5,6])
Ctranspose is its own inverse:
@transposed_list = transpose(0,1,@a); # ([1,3,5],[2,4,6])
@orig_list = transpose(0,1,@transposed_list); # (([1,2],[3,4],[5,6])
@a == @orig_list; # true
If Ctranspose refers to a dimension that does not exist, empty
dimensions autovivify as necessary:
@row_vector = (1,2,3,4);
@col_vector = transpose(0,1,@row_vector); # ([1],[2],[3],[4])
=head2 Reordering Dimensions
An alternative form of Ctranspose uses the first argument as a list ref
to specify a new order for the dimensions:
transpose [0,3,4,1,2], @arr;
If some dimensions are not specified in the first argument, those
dimensions are left in their current order:
# Where @arr is a rank 5 array...
transpose ([3], @arr) == transpose ([3,0,1,2,4], @arr);
transpose ([0,3], @arr) == transpose ([0,3,1,2,4], @arr);
This syntax allows multidimensional arrays to be reduced along any
dimension:
@sumover_1st_dim = reduce ^_ + ^_, @arr[ 0..; |i; * ];
@sumover_3rd_dim = reduce ^_ + ^_, transpose([3],@arr)[0..; |i; * ];
Note that Creduce is from RFC 76, and C|i is from RFC 207.
=head2 Aliasing
Ctranspose does not make a copy of the elements of its arguments; it
simply create an alias:
@row_vector = (1,2,3,4);
@col_vector = transpose(0,1,@row_vector); # ([1],[2],[3],[4])
$col_vector[[0,1]] = 0;
@row_vector == (1,0,3,4); # True
=head2 Optional Extra: Dimension Insert
To move a dimension and insert it before some other dimension, the
following syntax may be used:
transpose ({3=2}, @arr) == transpose ([0,1,3,2,4], @arr);
which inserts dimension 3 in front of dimension 2.
=head1 IMPLEMENTATION
RFC 90 discusses possible approaches to implementing aliasing.
=head1 REFERENCES
RFC 76: Builtin: reduce
RFC 90: Arrays: merge() and unmerge()
RFC 148: Arrays: Add reshape() for multi-dimensional array reshaping
RFC 207: Arrays: Efficient Array Loops
Re: TAI and Unix epoch issues
Nathan Wiger wrote: I think we should definitely maintain this in UTC, since this is how UNIX works natively. If we're standardizing on the UNIX epoch we should standardize on UTC clock as well. Blech. Now I'm not sure after re-reading the thread starting here: http://www.mail-archive.com/perl6-language-datetime%40perl.org/msg3.html How about this: Somebody else decide and I'll stick it in as a not in v4 of RFC 99, which will be the frozen version. -Nate
RFC 152 (v2) Replace invocant in @_ with self() builtin
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace invocant in @_ with self() builtin
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 24 Aug 2000
Last Modified: 24 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 152
Version: 2
Status: Frozen
=head1 ABSTRACT
Currently, the invocant is passed into a sub as the first element of @_,
leading to the familiar construct:
my $self = shift;
However, this is a big PITA. In particular, if you support several
different calling forms (like CGI.pm), you have to check whether $_[0]
is a ref or class name, etc.
This RFC, therefore, proposes a new builtin called Cself() which will
return the correct invocant information. This has the added advantage
that it is consistent with Ccaller(), Cwant(), ref(), and other
context functions.
=head1 DESCRIPTION
=head2 Syntax
The new function Cself() would be called in the following way:
sub fullname {
my $self = self;
@_ ? $self-{STATE}-{fullname} = $_[0]
: $self-{STATE}-{fullname};
}
sub my_junk {
my $this = self;
$this-fork_o_matic(@_);
}
# Or even...
sub error {
carp @_ if self-config('VerboseErrors');
}
sub uid {
@_ ? self-{uid} = $_[0]
: self-{uid};
}
The return value of Cself() would be similar to the current invocant
in $_[0], with increased flexibility. In particular, it can be called
anywhere and everywhere, not just within a method.
Depending on the context it's called in, the return value of Cself()
will be:
1. A reference to the object, within an object method
2. The name of the package, within a package
3. Undef, if a sub is not called as a method
These different return values give us the ability to call Cself()
anywhere within Perl 6 code:
package MyPackage;
# ... many other functions ...
sub do_stuff {
print "Hello, @_" if self-config('Yep');
}
self-do_stuff; # MyPackage-do_stuff
package main;
my $mp = new MyPackage;
$mp-config('Yep') = 1;
$mp-do_stuff('Nate');# prints "Hello, Nate"
In addition, having a routine called Cself() has the major advantage
that it hides the internal magic and scoping from the user. Just like
using Cwant() instead of a special variable called C$WANT, Cself()
makes using and comprehending contexts easy, simply changing the Perl
5 rule:
"The invocant is passed into subs as $_[0] in OO contexts"
To the simpler still:
"The invocant is always gotten by calling self()"
This provides a consistent interface, since Cself() can be called
anywhere, just like Ccaller(), Cwant(), and other context functions.
=head2 Arguments against Cuse invocant
This RFC was released prior to, and remains in opposition to, RFC 233,
which proposes a Cuse invocant pragma that provides the flexibility to
name the invocant anything you want.
As many have noted, Perl is already hard enough. Cuse invocant only
gives us multiple ways to do something without adding value, only
confusion, by promoting an inconsistent interface. Like providing a
means to rename C@ARGV and CSTDIN because a person prefers C@args
and Coutput, Cuse invocant further complicates an issue which should
only be made easier.
The author of this RFC Bloves Perl and loves its flexibility. However,
just like choosing a name for Ccaller, Cwant, Cprint, C@ARGV,
and so forth, we need to choose a name for Cself as well to ease the
burden on the programmer. "Choosing an interface" does not amount to
"being un-Perlish" as some might purport to suggest. In fact, just the
opposite: We're decreasing the amount of time a user has to spend
decoding somebody else's invocant naming scheme by providing a very
Perlishly-named function. BThis makes things easier.
If it is vital that the invocant must be named something specific, then
a person can always use a sub wrapper, tie, or a typeglob to rename it
appropriately. Actually, they don't even have to go to these extremes
since they can still do this:
sub getdata {
my $this = self;
return $this-{DATA}-{$_[0]};
}
(that is, assign to a custom variable) anywhere they want to.
Finally, the author would be more than happy to settle for the selection
of something different than Cself, such as Cthis(), C$SELF, or
even C$ME. The main point is that we need to choose something, because
doing so makes the language more consistent and easier (combatting two
widespread criticisms of Perl).
=head1 IMPLEMENTATION
Replace the invocant usually included in $_[0] with Cself(). Stop
passing the invocant in @_.
=head1 MIGRATION
Backwards compatibility is simple. Subs can simply have the expression:
unshift @_, self if self;
Added as the first line of the sub, since Cself() will return undef if
not in an OO context.
=head1 REFERENCES
Critique of the Cuse invocant pragma:
http://www.mail-archive.com/perl6-language@perl.org/msg03952.html
Outline of the
RFC 279 (v1) my() syntax extensions and attribute declarations
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
my() syntax extensions and attribute declarations
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 24 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 279
Version: 1
Status: Developing
=head1 ABSTRACT
This RFC fleshes out variable declarations with Cmy, and also proposes
a way to assign attributes without the need for a Cmy anywhere.
=head1 DESCRIPTION
Camel-3 shows some interesting hints of what's been proposed for Cmy
declarations:
my type $var :attribute = $value;
And we all know that you can use Cmy to declare a group of variables:
my($x, $y, $z);
Here's the issues:
1. How do the two jive together?
2. Should it be possible to assign attributes to individiual elements
of hashes/arrays? (yes)
=head2 Cohesive Cmy syntax
This RFC proposes that you be able to group multiple variables of the
same type within parens:
my int ($x, $y, $z);
my int ($x :64bit, $y :32bit, $z);
It seems most logical that:
1. The type will be the same across variables; this is common
usage in other languages because it makes sense.
2. The attributes will be different for different variables.
As such, multiple attributes can be assigned and grouped flexibly:
my int ($x, $y, $z) :64bit; # all are 64-bit
my int ($x, $y, $z :unsigned) :64bit; # plus $z is unsigned
Note that multiple types cannot be specified on the same line. To
declare variables of multiple types, you must use separate statements:
my int ($x, $y, $z) :64bit;
my string ($firstname, $lastname :long);
This is consistent with other languages and also makes parsing
realistic.
=head2 Assigning attributes to individual elements of hashes/arrays
This is potentially very useful. ":laccess", ":raccess", ":public",
":private", and others spring to mind as potential candidates for this.
This RFC proposes that in addition to attributes being assignable to a
whole entity:
my int @a :64bit; # makes each element a 64-bit int
my string %h :long; # each key/val is long string
They can also be declared on individual elements, without the need for
Cmy:
$a[0] :32bit = get_val; # 32-bit
$r-{name} :private = "Nate"; # privatize single value
$s-{VAL} :laccess('data') = ""; # lvalue autoaccessor
However, a problem arises in how to assign types to singular elements,
since this requires a Cmy:
my int $a[0] :64bit; # just makes that single element
# a lexically-scoped 64-bit int?
my string $h{name} = ""; # cast $h{name} to string, rescope %h?
Currently, lexical scope has no meaning for individual elements of
hashes and arrays. However, assigning attributes and even types to
individual elements seems useful. There's two ways around this that I
see:
1. On my'ing of an individual hash/array element, the
entire hash/array is rescoped to the nearest block.
2. Only the individual element is rescoped, similar
to what happens when you do this:
my $x = 5;
{
my $x = 10;
}
Either of these solutions is acceptable, and they both have their pluses
and minuses. The second one seems more consistent, but is potentially
extremely difficult to implement.
=head1 IMPLEMENTATION
Hold on.
=head1 MIGRATION
None. This introduces a more flexible syntax but does not break old
ones.
=head1 REFERENCES
Camel for the Cmy syntax.
Re: Perlstorm #0040
On Sun 24 Sep, Hugo wrote:
In [EMAIL PROTECTED], Richard Proctor
writes
:
:TomCs perl storm has:
:
: Figure out way to do
:
: /$e1 $e2/
:
: safely, where $e1 might have '(foo) \1' in it.
: and $e2 might have '(bar) \1' in it. Those won't work.
:
:If e1 and e2 are qr// type things the answer might be to localise
:the backref numbers in each qr// expression.
:
:If they are not qr//s it might still be possible to achieve if the
:expansion of variables in regexes is done by the regex compiler it
:could recognise this context and localise the backrefs.
:
:Any code like this is going to have real problem with $1 etc if used
:later, use of assignment in a regex and named backrefs (RFC 112) would
:make this a lot safer.
I think it is reaonable to ask whether the current handling of qr{}
subpatterns is correct:
perl -wle '$a=qr/(a)\1/; $b=qr/(b).*\1/; /$a($b)/g and print join ":", $1,
pos for "aabbac"' a:5
I'm tempted to suggest it isn't; that the paren count should be local
to each qr{}, so that the above prints 'bb:4'. I think that most people
currently construct their qr{} patterns as if they are going to be
handled in isolation, without regard to the context in which they are
embedded - why else do they override the embedder's flags if not to
achieve that?
This seams the right way to go
The problem then becomes: do we provide a mechansim to access the
nested backreferences outside of the qr{} in which they were referenced,
and if so what syntax do we offer to achieve that? I don't have an answer
to the latter, which tempts me to answer 'no' to the former for all the
wrong reasons. I suspect (and suggest) that complication is the only
reason we don't currently have the behaviour I suggest the rest of the
semantics warrant - that backreferences are localised within a qr().
With the suggestions from RFC 112, with assignment within the regex and
named backreferences, this provides a solution for anyone trying to
get at a backref inside of a nested qr(), I think this is a reasonable way
forward.
I lie: the other reason qr{} currently doesn't behave like that is that
when we interpolate a compiled regexp into a context that requires it be
recompiled, we currently ignore the compiled form and act only on the
original string. Perhaps this is also an insufficiently intelligent thing
to do.
Hugo
Yes, this and MJDs comment about the reentrant regex engine. I will stick
this in an RFC in a few minutes.
Richard
--
[EMAIL PROTECTED]
RFC 276 (v1) Localising Paren Counts in qr()s.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Localising Paren Counts in qr()s.
=head1 VERSION
Maintainer: Richard Proctor [EMAIL PROTECTED]
Date: 24 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 276
Version: 1
Status: Developing
=head1 ABSTRACT
The Paren Counts and backreferences should be localised in each qr(), to
prevent surprises when qr()s are used in combination.
=head1 DESCRIPTION
TomCs perl storm #0040 has:
Figure out way to do
/$e1 $e2/
safely, where $e1 might have '(foo) \1' in it.
and $e2 might have '(bar) \1' in it. Those won't work.
=head2 DISCUSSION
Me: If e1 and e2 are qr// type things the answer might be to localise
the backref numbers in each qr// expression. Use of assignment in a regex
and named backrefs (RFC 112) would make this a lot safer.
Hugo:
I think it is reaonable to ask whether the current handling of qr{}
subpatterns is correct:
perl -wle '$a=qr/(a)\1/; $b=qr/(b).*\1/; /$a($b)/g and print join ":", $1,
pos for "aabbac"'
a:5
I'm tempted to suggest it isn't; that the paren count should be local
to each qr{}, so that the above prints 'bb:4'. I think that most people
currently construct their qr{} patterns as if they are going to be
handled in isolation, without regard to the context in which they are
embedded - why else do they override the embedder's flags if not to
achieve that?
The problem then becomes: do we provide a mechansim to access the
nested backreferences outside of the qr{} in which they were referenced,
and if so what syntax do we offer to achieve that? I don't have an answer
to the latter, which tempts me to answer 'no' to the former for all the
wrong reasons. I suspect (and suggest) that complication is the only
reason we don't currently have the behaviour I suggest the rest of the
semantics warrant - that backreferences are localised within a qr().
I lie: the other reason qr{} currently doesn't behave like that is that
when we interpolate a compiled regexp into a context that requires it be
recompiled, we currently ignore the compiled form and act only on the
original string. Perhaps this is also an insufficiently intelligent thing
to do.
MJD:
Interpolated qr() items shouldn't be recompiled anyway. They should
be treated as subroutine calls. Unfortunately, this requires a
reentrant regex engine, which Perl doesn't have. But I think it's the
right way to go, and it would solve the backreference problem, as well
as many other related problems.
Me: You can access the nested backreferences outside of the qr{} in which
they were referenced by use of the named backref see RFC 112.
=head2 AGREEMENTS
The paren count in each qr() is localised to each qr().
There is no way to access the nested backrefernces outside of the qr() by
number they may be accessed by name (see RFC 112).
The regex engine must be made re-entrant.
The regex compiler should not need to recompile qr()s when used as part of
another regex.
=head1 IMPLENTATION
The Regex engine must be made re-entrant.
The expansion of variables in regexes must be driven by the regex compiler
(Same problem as for RFCs 112, 166 ...)
=head1 REFERENCES
Perlstorm #0040 from TomC.
RFC 112: Assignment within a regex
Re: RFC 275 (v1) Add 'tristate' pragma to allow undef to take on NULL semantics
=head1 TITLE Add 'tristate' pragma to allow undef to take on NULL semantics ... The Ctristate pragma allows for undef to take on the RDBMS concept of CNULL, in particular: 1. Any math or string operation between a NULL and any other value results in NULL Any math or string or logical operation... 2. No NULL value is equal to any other NULL 3. A NULL value is neither defined nor undefined Can we have an isnull() function then, please. Otherwise there's no operation to test for nullness. PS: Nullness? Nullility?
Re: Perl6Storm: Intent to RFC #0101
Adam Turoff [EMAIL PROTECTED] writes: I plan to offer a more formal RFC of this idea. Z. =item perl6storm #0101 Just like the "use english" pragma (the modern not-yet-written version of "use English" module), make something for legible fileops. is_readable(file) is really -r(file) Has unpleasant syntax saying "is_readable". Should be like normal English predicates. Get the idea you do. Is better even the Lisp -p convention! What's wrong with doing it like I (and maybe a few others) speak, and saying "readable(file)"? The "is_" prefix serves only to make predicates impossible to read out, leading to thinkos. [...] -- Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED] Compugen Ltd. |Tel: +972-2-5713025 (Jerusalem) \ We recycle all our Hz 72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`- Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: Perl6Storm: Intent to RFC #0101
Ariel Scolnicov wrote: is_readable(file) is really -r(file) Has unpleasant syntax saying "is_readable". Should be like normal English predicates. Get the idea you do. Is better even the Lisp -p convention! What's wrong with doing it like I (and maybe a few others) speak, and saying "readable(file)"? The "is_" prefix serves only to make predicates impossible to read out, leading to thinkos. Yeah, I tend to agree. PHP does this terribly nastily with crap like is_readable($file); is_executable($file); is_directory($file); Bleeech! Drop the is_ , I agree: readable($file); executable($file); directory($file); In fact, I'd much rather still a more generic function like 'want' that takes a list of things to check: file($file); # does it exist? file($file, 'r'); # is it readable? file($file, 'w'); # is it writable? file($file, 'd'); # is it a directory? file($file, 'wd'); # is it a writable directory? file($file, 'dw'); # same thing Otherwise we run the risk of 200 builtins just to check file types and modes on all the different platforms -Nate
Re: RFC 259 (v2) Builtins : Make use of hashref context for garrulous builtins
=item Cstat/Clstat
'blksize' Preferred block size for file system I/O
'blocks'Actual number of blocks allocated
Either "blocks" and "blocksize", or "blks" and "blksize", I think
What's there is what's been in perlfunc for ages, and stat.man for eons.
I think it might be a mistake to change it.
=item Cgetpw*
'name' Username
I'd really like this to be 'user', but it makes it inconsistent with the
other functions, so either way.
Again, I was working from the original man page.
'dir' Home directory
'homedir' or 'home' are _much_ better for us sysadmins...
Not if you sysadmins are familiar with the UNIX documentation, whence *all*
these names are taken! ;-)
=item Cgethost*
'aliases' Other host names
An array/arrayref (I hope)?
I don't think so. I suggest you need a separate RFC to propose semantic
changes like this and:
Y'know, this C-based interface has always sucked. ...
I know this isn't directly related to your RFC, but I needed to bring it
up. Seems like adding the upack('C4') thing to the gethost* functions
wouldn't be that hard and would make these common tasks a lot easier.
Damian
Re: RFC 259 (v2) Builtins : Make use of hashref context for garrulousbuiltins
'dir' Home directory
'homedir' or 'home' are _much_ better for us sysadmins...
Not if you sysadmins are familiar with the UNIX documentation, whence *all*
these names are taken! ;-)
Well, I've always hated it, and most everyone I know does too. And my
man pages say this:
Linux:
GETPWNAM(3) Linux Programmer's Manual GETPWNAM(3)
NAME
getpwnam, getpwuid - get password file entry
snip
The passwd structure is defined in pwd.h as follows:
struct passwd {
char*pw_name; /* user name */
char*pw_passwd; /* user password */
uid_t pw_uid; /* user id */
gid_t pw_gid; /* group id */
char*pw_gecos; /* real name */
char*pw_dir;/* home directory */
char*pw_shell; /* shell program */
};
Solaris:
Standard C Library Functions getpwnam(3C)
NAME
getpwnam, getpwnam_r, getpwent, getpwent_r, getpwuid,
getpwuid_r, setpwent, endpwent, fgetpwent, fgetpwent_r - get
password entry
snip
struct passwd {
char *pw_name; /* user's login name */
char *pw_passwd;/* no longer used */
uid_t pw_uid; /* user's uid */
gid_t pw_gid; /* user's gid */
char *pw_age; /* not used */
char *pw_comment; /* not used */
char *pw_gecos; /* typically user's full name */
char *pw_dir; /* user's home dir */
char *pw_shell; /* user's login shell */
};
So I suggest we change 'gcos' to 'gecos' then. Should we add the pw_
prefix too? ;-)
-Nate
P.S. Seriously, I don't care that much, and I'm not going to the mat on
this one. I'm way past burned out.
Re: RFC 275 (v1) Add 'tristate' pragma to allow undef to take on NULL semantics
Nathan Wiger wrote: Jeremy Howard wrote: Can we have an isnull() function then, please. Otherwise there's no operation to test for nullness. PS: Nullness? Nullility? ... use tristate; $a = undef; carp "\$a is null!" unless defined($a); That way, "defined($a)" will always return false for the above, regardless of the "use tristate" pragma. It seems more consistent in keeping with the "undef really means uninitialized" idea too. Yes, that's nullirific! It would be good to make that clear in the RFC.
Re: RFC 275 (v1) Add 'tristate' pragma to allow undef to take on NULL semantics
Jeremy Howard wrote: Yes, that's nullirific! It would be good to make that clear in the RFC. :-) Will do. -Nate
Re: perl6storm #0050
On Sat, 23 Sep 2000, raptor wrote: On Thu, 21 Sep 2000, Tom Christiansen wrote: =item perl6storm #0050 Radical notion: consider removing precedence. Wrong precedence makes people miserable. What if we have these 2 rules or no rules AND we can set manualy the precedence of all operators... as in PROLOG (op(precedencePriority,associativity!,operator)). I think this would be very unwise. Whenever adding a feature, we need to ask if the power granted outweighs the potential pitfalls created; in this case, I don't think it does. The potential problems of being able to assign precedence as you see fit (talk about action at a distance!) are enormous, and it does not seem to lend the same kind of elegant power that, for example, Damian's HOFs do. Dave
RFC 280 (v1) Tweak POD's CEltEgt
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Tweak POD's CEltEgt =head1 VERSION Maintainer: Simon Cozens [EMAIL PROTECTED] Date: 24 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 280 Version: 1 Status: Developing =head1 ABSTRACT CEltEgt is not as intuitive as it could be. =head1 DESCRIPTION In Perl 5.6.0, we altered the behaviour of the CEltEgt construct in POD, so that you could say CCEltElt ... EgtEgt to avoid the problem that C $foo-bar would be ended by the arrow. However, this isn't too Perlish, and there's an easier solution; give the CEltEgt the same semantics as a single quoted string with Cq//. That is: =over 1 =item * Do away with the need to escape stuff inside CEltEgt, because that stops you cutting and pasting the code. =item * Allow the use of alternate delimiters to avoid the arrow problem. C$xyz C/$foo-bar/ =back =head1 IMPLEMENTATION Just some tweaks to CPOD::Parser, haha. =head1 REFERENCES None.
RFC 282 (v1) Open-ended slices
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Open-ended slices
=head1 VERSION
Maintainer: Simon Cozens [EMAIL PROTECTED]
Date: 24 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 282
Version: 1
Status: Developing
=head1 ABSTRACT
The dreaded C@array[$foo...] rears its ugly head again.
=head1 DESCRIPTION
How many times have you wanted Bjust the last two return values from a
function? And how many times have you got frustrated that you can't work
out how many things there are in a list and you have to decant it to an
array:
@thingy = function()
for (@thingy[3..$#thingy]) { ... }
Horrible, isn't it? People want something better.
I thought about it last year or so, and produced a couple of patches. It
seemed then that the right syntax was not, for instance:
(function())[3...-1]
because sometimes you want C$x..$y to return the empty list, but
actually:
(function())[3...]
(Or C[3..]. It doesn't matter.)
Someone else on Perl5-Porters wanted this recently too, so it isn't just
me.
=head1 IMPLEMENTATION
It's new syntax, so it isn't going to break anything, and I did produce
patches against 5.6, so it is possible. It's a question of adding
another rule to the grammar, which flags that the slice should be
computed at run time.
=head1 REFERENCES
None.
RFC 283 (v1) Ctr/// in array context should return a histogram
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Ctr/// in array context should return a histogram =head1 VERSION Maintainer: Simon Cozens [EMAIL PROTECTED] Date: 24 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 283 Version: 1 Status: Developing =head1 ABSTRACT Ctr/// in array context should return a histogram explaining the number of matches for each letter in the pattern. =head1 DESCRIPTION This has been on the Perl 5 to-do list for ages and ages. The idea is that when you're transliterating a bunch of things, you want to know how many of each of them matched in your original string. For instance, while Ctr/x// will count the x's, Ctr/xy// will count both x's and y's - you don't know how many of each. So, the proposal is that Ctr in the array context should return a hash, like this: (%foo) = "xyzzy" =~ tr/xyz// # %foo is ( x = 1, y = 2, z = 3); =head1 IMPLEMENTATION I posted a patch to Perl 5.6 to do this some time back; it's a very simple matter of constructing the hash and incrementing the values every time you do a transliteration of a character. Of course, since we don't know what Perl 6's transliteration operator's going to look like, it's hard to know how to implement an extension to it... =head1 REFERENCES None.
RFC 284 (v1) Change C$SIG{__WARN__} and C$SIG{__DIE__} to magic subs
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Change C$SIG{__WARN__} and C$SIG{__DIE__} to magic subs
=head1 VERSION
Maintainer: Simon Cozens [EMAIL PROTECTED]
Date: 24 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 284
Version: 1
Status: Developing
=head1 ABSTRACT
It sounds really stoopid to say C$SIG{__WARN__} on a machine which
doesn't have signals.
=head1 DESCRIPTION
Perl 6 is going to be portable to all kinds of system, just like Perl 5.
Some of those systems won't have signals, so it's time to question why
the warn and die hooks are implemented as signal handlers.
Instead, let's implement them as magic subroutines CWARN and CDIE
like CBEGIN and CEND. This seems more consistent anyway. Well, to
me.
=head1 IMPLEMENTATION
Call subroutines CWARN and CDIE instead of the signal handler
versions. Everything else stays the same.
=head1 REFERENCES
None.
RFC 287 (v1) Improve Perl Persistance
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Improve Perl Persistance =head1 VERSION Maintainer: Adam Turoff [EMAIL PROTECTED] Date: 24 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 287 Version: 1 Status: Developing =head1 ABSTRACT Many mechanisms exist to make perl code and data persistant. They should be cleaned up, unified, and documented widely within the core documentation. =head1 DESCRIPTION Tom Christiansen proposed this in his perl6storm message: =item perl6storm #0022 make marshalling easy. core module? would this allow for easy persistence of data structures other than dbm files? general persistence is hard, right? can this be an attribute? Python offers one way to make code/data persistant: the Cpickle interface. More complex serialization can be accomplished through the 'shelve' interface or DBM files. This capability is quite useful, widely known and easily used. Perl, by comparison, offers Data::Dumper, which can serialize Perl objects that are rather asymetrically reconstituted by using Ceval or Cdo. Perl also offers solid, simple interfaces into DBM and Berkeley DB files, and offer a well known, low-level serialization mechanism. CPAN offers many other serialization modules that are only slightly different than Data::Dumper. This plethora of serialization mechanisms confuses users and adds to code bloat when multiple modules each use different serialization mechanisms that are all substantially similar. Something similar to Python's Cpickle interface should be added into Perl as a builtin; this feature should have a symmetric "restore" builtin (eg save()/restore(), freeze()/thaw(), dump()/undump()...). Furthermore, Perl's low level serialization machinery (DBM, SDBM, GDBM, Berkeley DB) should be unified into a single core module, where the underlying DBM implementations are pluggable drivers, like DBI's DBD infrastructure. =head1 IMPLEMENTATION First, the issue of adding builtin serialization functions needs to be addressed. This is a language issue because serialization should be more visible than it is today, and the best way to accomplish that is to include this feature as a pair of builtin functions. If this feature is implemented through a core module, that module might best be presented as a pragmatic module. Finally, although this proposal describes a simple matter of programming, some of the issues (such as pluggable interfaces) are best hashed out at a language-design level, so that they may be used elsewhere, easily. =head1 REFERENCES Python Pocket Reference, Chapter 12 perl6storm
RFC 288 (v1) First-Class CGI Support
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE First-Class CGI Support =head1 VERSION Maintainer: Adam Turoff [EMAIL PROTECTED] Date: 24 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 288 Version: 1 Status: Developing =head1 ABSTRACT Perl is frequently used in CGI environments. It should be as easy to write CGI programs with perl as it is to write commandline text filters. =head1 DESCRIPTION Tom Christiansen proposed this in his perl6storm message: =item perl6storm #0025 Make -T the default when operating in a CGI env. That is, taintmode. Will this kill us? Close to it. Tough. Insecurity through idiocy is a problem. Make them *add* a switch to make it insecure, like -U, if that's what they mean, to disable tainting instead. and this: =item perl6storm #0026 Make CGI programming easier. Make as first class as @ARGV and %ENV for CLI progging. Perl6 should be *easier* to write CGI programs than Perl5. One way to accomplish this is to add a C-cgi option to Perl, so that all of the mechanical setup is done automatically. That setup could also be done through a Cuse cgi; pragma. To make CGI programming easier, this option/pragma should: =over 4 =item * Turn on tainting =item * Parse the CGI context, returning CGI variables into %CGI =item * Offer simple functions to set HTTP headers (e.g. content type, result codes) =item * Load quickly =item * Not take up gobs of memory =back All of the other features offered by Lincoln Stein's CGI.pm should remain, but should not be deeply integrated into Perl6. =head1 IMPLEMENTATION Write a very small cgi.pm module that does as little as possible, probably based on Lincoln's code. Add a C-cgi commandline switch, and/or turn on tainting through a Cuse cgi pragma. =head1 REFERENCES CGI.pm perl6storm
RFC 290 (v1) Remove -X
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Remove -X =head1 VERSION Maintainer: Adam Turoff [EMAIL PROTECTED] Date: 24 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 290 Version: 1 Status: Developing =head1 ABSTRACT File tests (-r/-w/-x/...) made sense when Perl's shellness was an attribute. Most new Perl programmers are not coming from a shell programming background, and the -X syntax is opaque and bizarre. It should be removed. =head1 DESCRIPTION Tom Christiansen proposed this in his perl6storm message: =item perl6storm #0101 Just like the "use english" pragma (the modern not-yet-written version of "use English" module), make something for legible fileops. is_readable(file) is really -r(file) note that these are hard to write now due to -s(FH)/2 style parsing bugs and prototype issues on handles vs paths. Aside from providing parsing bugs and prototype issues, the -X syntax is strange and confusing to many Perl programmers who are completely unfamiliar with Bourne shell syntax. The prefered mechanism for file tests should be more legible, using terms like 'readable(FOO)' and 'writeable(FOO)' instead of the opaque '-r FOO' and '-x FOO'. Furthermore, these tests should remain useable where appropriate on any I/O mechanism, not just files. =head1 MIGRATION ISSUES p52p6 would convert instances of -X to the appropriate legible test. Perl programmers happy with the -X syntax will need to get used to the lengthier replacement. =head1 IMPLEMENTATION None required. =head1 REFERENCES perl6storm
RFC 278 (v1) Additions to 'use strict' to fix syntactic ambiguities
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Additions to 'use strict' to fix syntactic ambiguities
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 24 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 278
Version: 1
Status: Developing
=head1 ABSTRACT
Several RFCs and many people have voiced concerns with different parts
of Perl's syntax. Most take issue with syntactic ambiguities and the
inability to easily tokenize Perl.
This RFC shows how these all boil down to a three central issues, and
how they can be solved with some simple additions to Cuse strict. By
default, Perl should remain as flexible as possible. By adding these
flags to Cuse strict, those who desire them can have all the benefits
of a stricter syntax, without hurting those that like these features.
=head1 DESCRIPTION
=head2 The Problems
=head3 Indirect Objects
RFC 244 proposes eliminating the bareword indirect object syntax because
this:
print STDERR @stuff;
Can be parsed as either of these:
STDERR-print(@stuff);
print(STDERR(@stuff));
Depending on your usage of CSTDERR other places in your program.
However, some of us like writing:
$q = new CGI;
Quite a bit, and consider this DWIMish.
=head3 Barewords vs. Functions
RFC 244 and others mention several problems with barewords such as:
name-stuff(@args); # name()-stuff or 'name'-stuff ?
Again, the fact that Perl can figure this out correctly is quite
DWIMish, and this functionality should not be removed by default.
=head3 Special Cases
Many special cases abound, such as the bare C// mentioned in RFC 135.
Again, this is stuff that makes Perl fun, and should not be taken out
of the language.
=head2 The Solutions
At first, these may not seem related. However, they very much are, and
in fact all boil down to only three issues which can be resolved with
additions to Cuse strict.
=head3 Function Parens - Cuse strict 'words'
This imposes a very simple restriction: barewords are not allowed. They
must be either quoted or specified with parens to indicate they are
functions. Note this solves the C%SIG problem from Camel:
use strict 'words';
$SIG{PIPE} = Plumber;# syntax error
$SIG{PIPE} = "Plumber"; # use main::Plumber
$SIG{PIPE} = Plumber(); # call Plumber()
In addition, this also forces users to disambiguate certain functions:
use strict 'words';
name-stuff(@args); # syntax error
'name'-stuff(@args);# 'name'-stuff
name::-stuff(@args);# ok too, same thing
name()-stuff(@args);# name()-stuff
$result = value + 42;# syntax error
$result = value() + 42; # value() + 42
$result = value( + 42); # value(42)
$result = 'value' + 42; # ok, if you think this is Java...
It's simple: barewords are not allowed.
=head3 Indirect Objects - Cuse strict 'objects'
Another major problem is ambiguous indirect objects. Under Cuse strict
'objects', the indirect object Imust be surrounded by braces:
use strict 'objects';
no strict 'words';
print STDERR @stuff; # print(STDERR(@stuff))
print "STDERR" @stuff; # syntax error
print {"STDERR"} @stuff; # 'STDERR'-print(@stuff)
print $fh @junk; # syntax error
print {$fh} @junk; # $fh-print(@junk)
This eliminates the possibility of ambiguity with indirect objects. When
combined with Cstrict 'words', code becomes even less ambiguous:
use strict qw(words objects);
$q = new 'CGI'; # syntax error
$q = new {'CGI'};# 'CGI'-new
$q = new ('CGI');# new('CGI')
$q = new (CGI());# new(CGI())
$q = new 'CGI' @args;# syntax error
$q = new {'CGI'} (@args);# 'CGI'-new(@args)
$q = new (CGI (@args)); # new(CGI(@args))
=head3 Syntactic Problems - Cuse strict 'syntax'
There are many other "little ambiguities" throughout Perl. Adding
Cstrict 'syntax' would remove these and require the user to specify
them explicitly. In this category fits the bare C// problem mentioned
in RFC 135, as well as several common "bugs" (mistakes).
Under this rule, the following would apply:
1. No more // by itself, you must use m//
2. Trailing conditionals would require parens
3. Precedence other than for basic math and boolean ops would
not apply
This is designed to force you to write clean, unambiguous code that
borders on being non-Perlish:
use strict 'syntax';
next if /^#/ || /^$/; # syntax error
next if m/^#/ || m/^$/; # syntax error
next if (m/^#/ || m/^$/); # ok
use strict 'syntax';
$data = $a + $b / $c - $d || $default or die; # no way
$data = ($a + $b / $c - $d) || $default or die;# nope
($data = ($a + $b / $c - $d) || $default) or die; # ok
Basically, the idea is to impose a truly unambiguous style so that
people don't get carried away with precedence and special cases.
=head2 Combining all these together
Let's look at an example of how all these
