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
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
Jeremy Howard wrote:
>
> Yes, that's nullirific!
>
> It would be good to make that clear in the RFC.
:-)
Will do.
-Nate
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
>
> =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
> > * 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.
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/
> =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.
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
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
[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
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(
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
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
>
>
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
> > =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
>> > '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
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
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
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
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
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
> "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
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
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
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
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
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
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
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,
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
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
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
48 matches
Mail list logo
