> =head1 IMPLEMENTATION
>
> Tricky.
>
> Perl needs to know about scalar context, list context, and "finite
> list" context. Presumably, if I/O routines behave this way, user
> subs should be able to behave this way as well. Might use the same
> machinery as lazy subs.
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/
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Generate module dependencies easily
=head1 VERSION
Maintainer: Adam Turoff <[EMAIL PROTECTED]>
Date: 24 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 289
Version: 1
Status: Developing
=head1
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
P
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
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add a "emit pod" runtime option to Perl
=head1 VERSION
Maintainer: Adam Turoff <[EMAIL PROTECTED]>
Date: 24 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 286
Version: 1
Status: Developing
=h
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Lazy Input
=head1 VERSION
Maintainer: Adam Turoff <[EMAIL PROTECTED]>
Date: 24 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 285
Version: 1
Status: Developing
=head1 ABSTRACT
Currently, fil
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
S
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
C 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: Developi
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 dr
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
The Perl 6 Development Log
=head1 VERSION
Maintainer: Simon Cozens <[EMAIL PROTECTED]>
Date: Sep 24 2000
Mailing List: [EMAIL PROTECTED]
Number: 281
Version: 1
Status: Developing
=head1 ABSTRAC
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Tweak POD's CEE
=head1 VERSION
Maintainer: Simon Cozens <[EMAIL PROTECTED]>
Date: 24 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 280
Version: 1
Status: Developing
=head1 ABSTRACT
CEE is
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: Fro
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Arrays: New operator ';' for creating array slices
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 8 Sep 2000
Last Modified: 24 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Standard support for opening i/o handles on scalars and arrays-of-scalars
=head1 VERSION
Maintainer: Eryq (Erik Dorfman) <[EMAIL PROTECTED]>
Date: 23 Aug 2000
Last Modified: 24 Sep 2000
Mailing List
Whatever is done, it should be clear that a situation that exists today should
not be permitted in the future. It should be impossible for a (corporate)
entity, based on the GPL, to restrict the redistribution of Perl, which is a
right seemingly granted by the AL. The conbination of the GPL's f
At 07:37 PM 9/24/00 -0400, Ben Tilly wrote:
>We have mere days to get any final RFCs in.
>
>Is there any significant objection to my proposing two?
>
>1) Perl should switch to something like an MIT license
> together with a trademark on Perl (likely with O'Reilly
> requested to care of the det
At 07:32 PM 9/24/00 -0400, Ben Tilly wrote:
[Major snippage here]
>>That the license places any obligations or exercises any level of control
>>over the output (the equivalent of the .o file) is a *big* issue. It would
>>mean in many cases that back ends not distributed with perl (with
>>corresp
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
>
We have mere days to get any final RFCs in.
Is there any significant objection to my proposing two?
1) Perl should switch to something like an MIT license
together with a trademark on Perl (likely with O'Reilly
requested to care of the details).
2) Continue dual-licensing GPL/AL with the
Dan Sugalski wrote:
>
>At 04:58 PM 9/22/00 -0400, Ben Tilly wrote:
>>Dan Sugalski wrote:
>>>At 11:01 AM 9/22/00 -0400, Ben Tilly wrote:
[...]
>>How many versions can you find of diff, awk, sed, etc?
>
>Yeah, but isn't that supposed to be a good thing? :)
Only if you don't have to port scripts bet
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.c
s/August/October/g;
Tim.
On Sun, Sep 24, 2000 at 07:51:25AM -0600, Nathan Torkington wrote:
> So that Larry isn't chasing a moving target, I've set a deadline of
> August 1 for freezing the RFCs. Ziggy has come up with a list of
> developing RFCs that are overdue for an update or status change,
Bradley M. Kuhn wrote:
>
>In general, I think this new license is bit more convoluted then it needs
>to
>be. I proposal generally the following measures. I am editing it up
>today,
>and I will post a version of my proposal tommorrow.
I am waiting for this before trying to draw up any proposal
Russ Allbery wrote:
>
> Is Perl keeping UTC or TAI? If we're standardizing on an epoch, we should
> also standardize on a clock; the difference is over ten seconds.
I think we should definitely maintain this in UTC, since this is how
UNIX works natively. If we're standardizing on the UNIX epoc
Jeremy Howard wrote:
>
> Yes, that's nullirific!
>
> It would be good to make that clear in the RFC.
:-)
Will do.
-Nate
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, "de
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: Dev
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Eliminate unquoted barewords from Perl entirely
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 24 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 277
Version: 1
Status: Devel
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
On Sat, Sep 23, 2000 at 11:32:58AM -0400, Karl Glazebrook wrote:
> Yes this is the point. I guess another way of looking at it is
> saying that 3*@a operates in a list context not a scalar context
Well, this shows that you entirely miss the problem of cryptocontexts.
Context is determined by the
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
=he
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
Ve
> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
CN> At 13:23 +0200 2000.09.20, Bart Lateur wrote:
>> This surely was a bad design decision from the hardware guys. Very
>> shortsighted.
CN> I don't know if it has anything to do with the hardware clock. It has to
CN> do with what the Mac O
Thanks for the feedback Uri.
Some specific points:
> PRL>pre tax_payable_on {
> PRL> $_[0] -= 20.00; # routinely underquote sales price
> PRL>}
>
> i assume like normal subs, that changes the original argument in the
> caller.
Correct. Guess I'd
> > * There's also no need to distinguish C and C,
> >since you've previously distinguished them by keyword. I would
> >suggest that either C be used for both types of
> >inheritance, or else the definition of an interface specification
> >just be a regular C.
>
>> > '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 t
> > =item C/C
> >
> > '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 fo
So that Larry isn't chasing a moving target, I've set a deadline of
August 1 for freezing the RFCs. Ziggy has come up with a list of
developing RFCs that are overdue for an update or status change, and
I expect working group chairs to focus discussion to get them wrapped
up.
http://dev.perl.or
Jeremy Howard wrote:
>
> Can we have an isnull() function then, please. Otherwise there's no
> operation to test for nullness.
>
> PS: Nullness? Nullility?
I've been thinking about how to test for nullirificity. The problem is
that introducing an 'isnull' keyword without a 'null' keyword seems
Good idea, I'm going to nitpick a few names now...
> =item C/C
>
> '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
> =item C
>
>
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
It was also described in one of the PDL RFCs ages ago.
The general data structure was described which basically
allows a:b:c slices, transposes (read arbitrary dimension
swapping) etc with no copy overhead.
In PDL
$a = zeroes(5000,4000,3000);
$b = $a->slice('2:5000:2,3:3000,0:3000:10')->xchg(
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
> =head1 TITLE
>
> Add 'tristate' pragma to allow undef to take on NULL semantics
>
<...>
>
> The C pragma allows for undef to take on the RDBMS concept of
> C, in particular:
>
>1. Any math or string operation between a NULL and any other
> value results in NULL
>
Any math or string or
[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
Karl Glazebrook:
> Well if a dimension has N elements then the numbering of the elements
> runs 0...N-1
>
> similarly if the shape has M dimensions, then the numbering of the
> dimensions is 0..M-1
>
> the arguments to reshape should be sizes not last elements (i.e. N's
> not N-1's).
>
> I think t
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 a
48 matches
Mail list logo
