Re: Implementing RFC 272

Buddha Buck wrote: > When I heard about transpose() (as well as reshape(), etc), I was > concerned about the time it would take to execute these complex > operations. To wit, naively, I believed that a lot of data shuffling > would be necessary. If I understand your message correctly this is ex

Re: RFC 23 (v5) Higher order functions

> DC> ^1 means $_[1], NOT $_[0] > > [snip. Last message repeated too many times.] > > If you have to do that, that is a good argument to follow the 'natural' > inclination. Not until $_[0] follows the natural inclination. > Again, why insist on an index when it re

Implementing RFC 272

This may be verging outside of the range of "language-data" and veering towards "internals", but I'd sort of like to hash out an idea to make sure that I'm thinking straight. When I heard about transpose() (as well as reshape(), etc), I was concerned about the time it would take to execute the

Re: Perlstorm #0040

> 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, Interpolated qr() items shouldn't be recompiled anyway. They should be treated as subroutine calls. Unfortunately, this requires a

Re: A common event loop

> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes: DLN> This too is something that would be very easy to do in DLN> everything-is-an-exception world. All events throw "EVENT-whatever" DLN> exceptions, and there you are. That is a nasty and expensive way of doing something 'simple'. And I

Re: RFC 153 (v2) New pragma 'autoload' to load functions and modules on-demand

> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> New pragma 'autoload' to load functions and modules on-demand You must have missed all the discussion on -internal and the discussions about moving things out of the core. Even an autoload pragma will not be needed. Upon inst

Re: RFC 23 (v5) Higher order functions

> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: >> Let me ask you: >> >> foo('a','b', 'c') >> >> Is 'b' the 1st parameter or the 2nd? DC> This is the classical mistake of confusing indices and ordinals. DC> The 1st argument is bound to the parameter whose index is [0], DC> The 2nd argu

Re: Perlstorm #0040

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 loca

Re: RFC 272 (v1) Arrays: transpose()

Jeremy Howard wrote: > (I'm not assuming the no-flattening thing, since that's another source of > angst altogether!) What is the no-flattening thing? Christian

Re: RFC 272 (v1) Arrays: transpose()

Karl Glazebrook wrote: > the arguments to reshape should be sizes not last elements (i.e. N's > not N-1's). Yup, it's simple: size (N) vs index range (0..N-1) > How does this sound? Logical and consistent ;) Christian

Re: RFC 272 (v1) Arrays: transpose()

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 oth

RFC 208 (v4) crypt() default salt

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE crypt() default salt =head1 VERSION Maintainer: Mark Dominus <[EMAIL PROTECTED]> Date: 11 Sep 2000 Last Modified: 23 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 208 Version: 4 Status: Fro

Re: RFC 272 (v1) Arrays: transpose()

Jeremy Howard wrote: > > Karl Glazebrook wrote: > > Jeremy Howard wrote: > > > > > > BTW, I notice that you're using dimension numbering starting at 0 for > your > > > transpose() examples. Is everyone happy to start at 0 rather than 1? > > > > OF COURSE!!!

RFC 275 (v1) Add 'tristate' pragma to allow undef to take on NULL semantics

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Add 'tristate' pragma to allow undef to take on NULL semantics =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 23 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 275 Versio

RFC 263 (v2) Add null() keyword and fundamental data type

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Add null() keyword and fundamental data type =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 19 Sep 2000 Last Modified: 23 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 263

RFC 103 (v3) Fix C<$pkg::$var> precedence issues with parsing of C<::>

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Fix C<$pkg::$var> precedence issues with parsing of C<::> =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 14 Aug 2000 Last Modified: 23 Sep 2000 Mailing List: [EMAIL PROTECTED] N

RFC 112 (v3) Asignment within a regex

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Asignment within a regex =head1 VERSION Maintainer: Richard Proctor <[EMAIL PROTECTED]> Date: 16 Aug 2000 Last Modified: 23 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 112 Version: 3 Sta

RFCing perl6storm #0003, #0035, #0050

I have an RFC already in the works that addresses these with additions to C. Hopefully out RSN. -Nate =item perl6storm #0003 Make parens "optionally mandatory" on function calls. use strict 'functions'; =item perl6storm #0035 Make A->B place A in string context, like => does. That way no

Perl6Storm: Intent to RFC #0101

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) note that these are hard to write now due to

Perl6Storm: Intent to RFC #0043

I plan to offer a more formal RFC of this idea. Z. =item perl6storm #0043 Write something that spits out module dependencies. Like makedep. A tool that sources but doesn't run? a program/module then spits out %INC might suffice. Can we autobundle with CPAN tricks?

Re: Perl6Storm: Intent to RFC #0000

Sounds good. Here's some stuff we had discussed on it: http://www.mail-archive.com/perl6-language@perl.org/msg03484.html http://www.mail-archive.com/perl6-language@perl.org/msg03487.html http://www.mail-archive.com/perl6-language@perl.org/msg03488.html http://www.mail-archive.com/perl6-language@p

Perl6Storm: Intent to RFC #0026

I plan to offer a more formal RFC of this idea. Z. =item perl6storm #0026 Make CGI programming easier. Make as first class as @ARGV and %ENV for CLI progging.

Perl6Storm: Intent to RFC #0025

I plan to offer a more formal RFC of this idea. Z. =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 wha

Perl6Storm: Intent to RFC #0004

I plan to offer a more formal RFC of this idea. Z. =item perl6storm #0004 Need perl to spit out pod/non-pod, like cc -E. Pod is too hard to parse. This would make catpod trivially implemented as a compiler filter.

Perl6Storm: Intent to RFC #0022

I plan to offer a more formal RFC of this idea. Z. =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?

Perl6Storm: Intent to RFC #0000

I plan to offer a more formal RFC of this idea. Z. =item perl6storm # This: ($a,$b) = ; should not drain whole ahndle on known LHS count, to rescue my($x) = ;

Re: RFC 263 (v1) Add null() keyword and fundamental data type

Russ Allbery wrote: use 'strict' is probably the difference between our code... I tend not to use it, because I wrote a bunch of code that didn't, initially, before I heard of it (maybe before it existed? I started with Perl 4.something), and haven't gotten it all converted so that it can be us

Re: RFC 83 (v3) Make constants look like variables

Nathan Wiger wrote: > Jeremy Howard wrote: > > > > Good question. I haven't tackled this in RFC 83, because it is a more > > general question about attribute syntax. We don't really have a good > > attribute syntax RFC yet, although Nate threw up some ideas a couple of days > > ago. Is someone int

Re: RFC 272 (v1) Arrays: transpose()

Karl Glazebrook wrote: > Jeremy Howard wrote: > > > > BTW, I notice that you're using dimension numbering starting at 0 for your > > transpose() examples. Is everyone happy to start at 0 rather than 1? > > OF COURSE!! > > anything else would be W

Perlstorm #0040

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 th

Re: RFC 263 (v1) Add null() keyword and fundamental data type

Glenn Linderman <[EMAIL PROTECTED]> writes: > Russ Allbery wrote: >> Perhaps I don't use those warnings in the same way that you do. I >> *very* rarely have undefined value warnings in my programs, and when I >> do they're usually not actually bugs, just things that require a >> different way of

Re: Hopefully last draft of AL

Ben Tilly <[EMAIL PROTECTED]> writes: > I think that you actually can have trademarks on the same name in > different areas as long as there is no possible confusion... Correct, at least in the US. -- Russ Allbery ([EMAIL PROTECTED])

Re: Hopefully last draft of AL

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. First, in a couple of different places, it unnecessarily makes restatements of what is alre

RE: Hopefully last draft of AL

Garrett Goebel wrote: > >From: Dan Sugalski [mailto:[EMAIL PROTECTED]] > > At 05:18 PM 9/22/00 -0500, Garrett Goebel wrote: [...] >It doesn't look like Larry'd have a good chance of trademarking "Perl" >anyways. Then again, I don't know much about trademarks. I think that you actually can have tr

Re: RFC 269 (v1) Perl should not abort when a required file yields a false value

> =head1 TITLE > > Perl should not abort when a required file yields a false value Damian already covered this in RFC 55: http://dev.perl.org/rfc/55.pod -Nate

Re: RFC 265 (v1) Interface polymorphism considered lovely

> >package Doggie; > > > >sub isborn { > >bless { @_ }, self; # ;-) > >} > >sub scratches ($\@;@) { > >... > >} > > > > > >package Doggie::Cute; > > > >use base 'Doggie'; > >use interface 'Pet'; > > > ># Our base class is 'Doggie', which does n

perl6storm ideas that are already covered

Just so we don't rehash issues that are already covered in other RFC's, since many are: > =item perl6storm #0015 > > merge tie and overloading. python's ease of doing this > makes this embarrassing. RFC 200: Objects: Revamp tie to support extensibility (Massive tie changes) > =item perl6storm

Re: RFC 83 (v3) Make constants look like variables

Jeremy Howard wrote: > > Good question. I haven't tackled this in RFC 83, because it is a more > general question about attribute syntax. We don't really have a good > attribute syntax RFC yet, although Nate threw up some ideas a couple of days > ago. Is someone interested in whipping up an RFC t

Re: PERL6STORM - tchrist's brainstorm list for perl6

On Sat, 23 Sep 2000 04:20:37 -0400 (EDT), Philip Newton wrote: >On Thu, 21 Sep 2000, Tom Christiansen wrote: > >> =item perl6storm #0035 >> >> Make A->B place A in string context, like => does. >> That way no A()->B naughtiness. > >While still allowing explicit A()->B? Of course. You can still

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

[EMAIL PROTECTED] wrote: > > Ilya Zakharevich wrote: > > ...Do you say you are confused by using vectors (=scalars) instead of > > arrays? > > I'm not having a problem with that personally but *many* users of PDL > have complained about being confused by this. > They assume ndim == array == perl

Re: RFC 272 (v1) Arrays: transpose()

Jeremy Howard wrote: > > BTW, I notice that you're using dimension numbering starting at 0 for your > transpose() examples. Is everyone happy to start at 0 rather than 1? OF COURSE!! anything else would be WRONG

RE: Hopefully last draft of AL

From: Dan Sugalski [mailto:[EMAIL PROTECTED]] > At 05:18 PM 9/22/00 -0500, Garrett Goebel wrote: > > From: Ben Tilly [mailto:[EMAIL PROTECTED]] > > > Garrett Goebel wrote: > > > > > > > > Can't a trademark be used to protect "Perl", even if the > > > > code is in the public domain? > > > > > > Yes

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

Ilya Zakharevich wrote: > > On Sat, Sep 23, 2000 at 10:41:07AM +1100, Jeremy Howard wrote: > > Many Perl users operate on lists of data. Requiring explicit loops every > > time a programmer wants to operate on a list is asking the programmer to fit > > in with how a computer thinks. That's not r

Re: RFC 272 (v1) Arrays: transpose()

[EMAIL PROTECTED] wrote: > How about (if perl6 allows passing arrays implicitly by reference > without arglist flattening) > > transpose @arr, $a, $b; # xchg > transpose @arr, {$a => $b}; # mv > transpose @arr, [0,3,4,1,2]; # PDL reorder > You know, I had just logged in to pos

Re: perl6storm #0050

> On Thu, 21 Sep 2000, Tom Christiansen wrote: > > > =item perl6storm #0050 > > > > Radical notion: consider removing precedence. > > Wrong precedence makes people miserable. > > (Some people already suggest that Perl only has two precedence rules: (1) > multiplication and division come before add

Re: perl6storm #0011: interactive perl mode

Philip Newton <[EMAIL PROTECTED]> writes: > On Thu, 21 Sep 2000, Tom Christiansen wrote: >> =item perl6storm #0011 >> perl w/o args with stdin and out ttys should be perl -de 0. >> saves novices from typing "perl" and getting confuddled. > I think it should print out a banner message, too. > A

perl6storm #0073

On Thu, 21 Sep 2000, Tom Christiansen wrote: > =item perl6storm #0073 > > kill bareword strings entirely. Including in places such as use? Well, I suppose we can get used to use 'strict'; . Any other "famous" incidences of barewords? (Maybe 'Foo::Blurf'->meth().) Cheers, Philip -- Phili

perl6storm #0060: formats

On Thu, 21 Sep 2000, Tom Christiansen wrote: > =item perl6storm #0060 > > formats and html doesn't mix nicely (not wysiwig). Neither do any > hidden chars, like ESC-blah. Can we do more for generating simple > clean transparent xml? Talking of ESC-blah, I've sometimes wanted to have a way to

perl6storm #0050

On Thu, 21 Sep 2000, Tom Christiansen wrote: > =item perl6storm #0050 > > Radical notion: consider removing precedence. > Wrong precedence makes people miserable. (Some people already suggest that Perl only has two precedence rules: (1) multiplication and division come before addition and subtr

Re: PERL6STORM - tchrist's brainstorm list for perl6

On Thu, 21 Sep 2000, Tom Christiansen wrote: > =item perl6storm #0035 > > Make A->B place A in string context, like => does. > That way no A()->B naughtiness. While still allowing explicit A()->B? Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>

perl6storm #0011: interactive perl mode

On Thu, 21 Sep 2000, Tom Christiansen wrote: > =item perl6storm #0011 > > perl w/o args with stdin and out ttys should be perl -de 0. > saves novices from typing "perl" and getting confuddled. I think it should print out a banner message, too. A couple of times I was wondering whether perl was

perl6storm #0010: kill all defaults

On Thu, 21 Sep 2000, Tom Christiansen wrote: > =item perl6storm #0010 > > Allow a way to kill *all* defaults at compile time. Or warn about them. > > no defaults; > use defaults 'none'; > use warnings 'defaults'; > > this is for anal python folks. What are defaults, in this conte