RE: RFC 288 (v1) First-Class CGI Support

> > General purpose output formatting: no, nyet, nein, non, "over > > my dead body". > I'm guessing you mean "nyet" to "general purpose formatting *only*". :-) > > After sending that last email, I was sitting here drinking a beer, and > it occured to me that tons of headers all the use same form

Re: RFC 288 (v1) First-Class CGI Support

* Adam Turoff ([EMAIL PROTECTED]) [26 Sep 2000 17:15]: > On Tue, Sep 26, 2000 at 05:02:02PM +1100, iain truskett wrote: > > Is there much point having a lightweight CGI module? If you say 'I want > > it to load quickly', I say 'get mod_perl'. > There's more to it than just loading quickly. It sh

Re: RFC 288 (v1) First-Class CGI Support

On Tue, Sep 26, 2000 at 05:02:02PM +1100, iain truskett wrote: > Is there much point having a lightweight CGI module? If you say 'I want > it to load quickly', I say 'get mod_perl'. There's more to it than just loading quickly. It should load quickly as in "load everything that's absolutely nece

Re: RFC 288 (v1) First-Class CGI Support

> The http_header() is a straw man intended to demonstrate that there > are issues with shoving all of the outgoing HTTP headers into a simple > variable. Not insoluable problems, but problems. Agreed. > I do like the idea of stacking HTTP headers and queueing them up > before the first print

Re: RFC 288 (v1) First-Class CGI Support

* Adam Turoff ([EMAIL PROTECTED]) [26 Sep 2000 16:44]: > On Mon, Sep 25, 2000 at 09:34:41PM -0700, Nathan Wiger wrote: > > Adam Turoff wrote: [...] > > If it imports a function, then it's a module. Perhaps what we should > > look at doing is providing a lightweight CGI module instead? Is there m

RFC 320 (v1) Allow grouping of -X file tests and add C builtin

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Allow grouping of -X file tests and add C builtin =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 25 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 320 Status: Developing =

Re: RFC 288 (v1) First-Class CGI Support

On Mon, Sep 25, 2000 at 09:34:41PM -0700, Nathan Wiger wrote: > Adam Turoff wrote: > > I'm thinking that whether the request came from a GET or a POST, > > the un(HTTP)-escaped values will be in %CGI, just as CGI::params() > > does. > > Like this? > >$CGI{fullname} = 'Nathan Wiger'; >$CG

Re: RFC 288 (v1) First-Class CGI Support

Adam Turoff wrote: > > I'm thinking that whether the request came from a GET or a POST, > the un(HTTP)-escaped values will be in %CGI, just as CGI::params() > does. Like this? $CGI{fullname} = 'Nathan Wiger'; $CGI{creditcard} = '1234-1234-1234-1234'; I'm 99% sure that's what you're sayin

Re: RFC 290 (v1) Remove -X

On Mon, Sep 25, 2000 at 09:18:40AM -0500, Jonathan Scott Duff wrote: > On Mon, Sep 25, 2000 at 06:02:51AM -, Perl6 RFC Librarian wrote: > > =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

Re: RFC 288 (v1) First-Class CGI Support

On Sun, Sep 24, 2000 at 11:16:46PM -0700, Nathan Wiger wrote: > > 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. > > First off, good idea, I do like this. Critiques: > > > Parse the CGI context, r

Re: RFC 244 (v1) Method calls should not suffer from the action on a distance

> Currently, > > foo->bar($baz) > > can be parsed either as C<<'foo'->bar($baz)>>, or as C> > depending on how the symbol C was used on other places. The proposal > is to always choose the first meaning: make C<< -> >> autoquote the bareword > on the left. Here is a question: How

Re: RFC 288 (v1) First-Class CGI Support

On Mon, Sep 25, 2000 at 03:17:33AM -0400, Alan Gutierrez wrote: > On 25 Sep 2000, Perl6 RFC Librarian wrote: > > First-Class CGI Support > > First-class CGI to me means HTML::Embperl. It means a hundred different things to a hundred different Perl programmers. Especially those writing mod_perl

Re: RFC 288 (v1) First-Class CGI Support

On Mon, Sep 25, 2000 at 11:43:53AM +0100, Hildo Biersma wrote: > For output generation, it becomes worse. Output generation is a separate problem space altogether. Related, but separate. Should embperl be turned on simply because I have a CGI program returning text, images or HTTP redirects

Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely

I personally have never had problems with these issues and would just as soon that this RFC didn't do through. However, I don't feel particularly strongly about most of it. Specifically: As to autoquoting the lefthand side of -> (thereby making it a class name), I don't particularly care. The

Re: RFC 288 (v1) First-Class CGI Support

On Mon, Sep 25, 2000 at 10:09:03AM -0500, [EMAIL PROTECTED] wrote: > > =head1 TITLE > > > > First-Class CGI Support > > [...] > > To make CGI programming easier, this option/pragma should: > > > Should the option/pragma also do "something" with regards to > files opened for writing? > > They (n

Re: RFC 288 (v1) First-Class CGI Support

On Mon, Sep 25, 2000 at 07:50:28AM +0100, Richard Proctor wrote: > On Mon 25 Sep, Perl6 RFC Librarian wrote: > > Turn on tainting > > What would it do on a platform that does not support Tainting? Is this a real issue? Is there a platform where tainting isn't supported? > > Parse the CGI conte

Re: RFC 287 (v1) Improve Perl Persistance

On Mon, Sep 25, 2000 at 09:40:52AM -0400, Michael Maraist wrote: > > Many mechanisms exist to make perl code and data persistant. They should > > be cleaned up, unified, and documented widely within the core > > documentation. > > But doesn't this go against TMTOWTDI. :) On the one hand, there'

Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely

On Mon, 25 Sep 2000, Michael Fowler wrote: > This RFC makes no mention of what happens to the following constructs: > > %foo = (bar => "baz"); This actually isn't a bareword (as I understand it), since the => operator quotes its LHS.

Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely

On Mon, Sep 25, 2000 at 05:49:21PM -0700, Nathan Wiger wrote: > Michael Fowler wrote: > > Honestly, if you're using both a stat class and a stat function in your > > code it's up to you to keep it straight > > Exactly my point. So why is this > >stat->mode > > Any different? It's not. Yes,

Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely

Michael Fowler wrote: > > Then say stat()->{'mode'} and stat::->mode, if it makes you feel better. Or > better yet, always say stat()->anything when you mean the function call. Either way is fine by me, but making Perl do one one place and the other the other place makes no sense. > Honestly,

Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely

On Mon, Sep 25, 2000 at 04:50:32PM -0700, Nathan Wiger wrote: > Is just as much of a pain because of action-at-a-distance. Solving this > problem with highly-specific solutions gains us nothing but more > syntactic inconsistencies and ambiguities, like these: > >stat->{'mode'} >stat->mode

Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely

> This is not a theoretical concern. If someone, at some point, defines sub > CGI {} your constructor suddenly fails. If you're using something along the > lines of Animal::Bear->new(), and the author of Animal.pm defines a Bear() > method, your constructor suddenly fails. This is action at a d

Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely

On Mon, Sep 25, 2000 at 03:50:20PM -0700, Nathan Wiger wrote: > So I assume you're suggesting that this: > > stat->{'mode'} > > be a call to stat(), which returns a hashref, but this: > > stat->mode > > would be a call to the method mode() in the class 'stat' > > That's not how I read

Re: RFC 290 (v1) Remove -X

On Mon, 25 Sep 2000 10:22:46 -0400, Clayton Scott wrote: >It: > + stacks multiple tests quite cleanly without excess verbiage > (if (-e && -T && -s && -x){...} gets a little tedious especially > if you don't use $_) Perhaps you want is to use $_. A "with" statement, or is it an expression, s

Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely

Michael Fowler wrote: > > You're beginning to blur your own fine line here. import is a class method > call using indirect object syntax. And, actually, per Schwern's RFC 253, require() would be too. Sometimes. > stat->{'mode'} > > No ambiguity here. So I assume you're suggesting that th

Re: RFC 143 (v2) Case ignoring eq and cmp operators

> Perl currently only has C and C operators which work case-sensitively. > It would be a useful addition to add case-insensitive equivalents. As I recall, the consensus the last time this came up was that C and C would be perfect examples w/in a RFC proposing a way to declare a function to take

Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely

On Mon, Sep 25, 2000 at 02:17:38PM -0700, Nathan Wiger wrote: >import Foo; You're beginning to blur your own fine line here. import is a class method call using indirect object syntax. > But notice the disconnect here: > >package Foo; >use base 'Bar'; > > Seems almost that: > >

RE: RFC 264 (v1) Provide a standard module to simplify the creation of source filters

Paul wrote: > > Given this level of complexity, it's perhaps not surprising that source > > code filtering is not commonly used. > > Whilst I don't have any problems with you module, I think you are > overstating the complexity of the existing situation. This should be all > t

Re: RFC 290 (v1) Remove -X

"John L. Allen" wrote: > > Ok, so that's pathological, but this isn't > > perl -e 'print -rwx($_)' > Undefined subroutine &main::rwx called at -e line 1. Well, it is still a little weird. You're still negating a subroutine call. And remember, if you have a sub called "r" this do

RE: RFC 264 (v1) Provide a standard module to simplify the creation of source filters

> This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Provide a standard module to simplify the creation of source filters > > =head1 VERSION > > Maintainer: Damian Conway <[EMAIL PROTECTED]> > Date: 20 September 2000 > Mailing List: [EMAIL PROTE

Re: RFC 292 (v1) Extensions to the perl debugger

On Mon, Sep 25, 2000 at 07:34:04PM -, Perl6 RFC Librarian wrote: > Mailing List: [EMAIL PROTECTED] Most of this RFC would probably be better off in perl6-stdlib; the debugger isn't really part of the language. That being said, however... > The ability to easily retrieve and edit your N mos

Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely

Michael Fowler wrote: > > This RFC makes no mention of what happens to the following constructs: > > use Foo; > require Foo; I don't mind a very few special cases. I would imagine that these might have to remain special: use Foo; require Foo; import Foo; package Foo; But n

Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely

On Sun, Sep 24, 2000 at 08:52:23PM -, Perl6 RFC Librarian wrote: > The solution is simple: All barewords must die. This RFC makes no mention of what happens to the following constructs: use Foo; require Foo; %foo = (bar => "baz"); These are legitimate, non-ambiguous uses of bar

Re: RFC 288 (v1) First-Class CGI Support

> "Uri" == Uri Guttman <[EMAIL PROTECTED]> writes: Uri> on the geek cruise, lincoln told me he had almost completed a total Uri> rewrite of CGI.pm. i have not heard anything about it since then. we Uri> should find out what he has done and possibly integrate it into perl6. CGI 3.01 is in the

Re: RFC 284 (v1) Change C<$SIG{__WARN__}> and C<$SIG{__DIE__}> to magic subs

> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes: SC> On Mon, Sep 25, 2000 at 03:10:47PM -0400, Uri Guttman wrote: >> in what order? like BEGIN and END? SC> Whatever, yes. >> what if you wanted a block scoped warn handler? SC> What about it? (Or did someone eat the "local" key

Re: RFC 290 (v1) Remove -X

On Mon, 25 Sep 2000, Nathan Wiger wrote: > > perl -e 'print -rwx $_' > > Can't call method "rwx" on an undefined value at -e line 1. > > Yeah, but read the error - Perl's parsing that as: > > [nwiger@matrix:~]$ perl -MO=Deparse -e 'print -rwx $_'; > print -$_->rwx; > -e syntax

Re: RFC 284 (v1) Change C<$SIG{__WARN__}> and C<$SIG{__DIE__}> to magic subs

On Mon, Sep 25, 2000 at 03:10:47PM -0400, Uri Guttman wrote: > in what order? like BEGIN and END? Whatever, yes. > what if you wanted a block scoped warn handler? What about it? (Or did someone eat the "local" keyword already?) > i think it would be better to have some explicit way of > sett

Re: RFC 284 (v1) Change C<$SIG{__WARN__}> and C<$SIG{__DIE__}> to magic subs

> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes: SC> On Mon, Sep 25, 2000 at 02:49:29PM -0400, Uri Guttman wrote: >> and how do they nest or get localized? with use signal you can install a >> lexically scoped handler or a package level handler. with WARN it looks >> like a global h

Re: RFC 284 (v1) Change C<$SIG{__WARN__}> and C<$SIG{__DIE__}> to magic subs

On Mon, Sep 25, 2000 at 02:49:29PM -0400, Uri Guttman wrote: > and how do they nest or get localized? with use signal you can install a > lexically scoped handler or a package level handler. with WARN it looks > like a global handler to me. They're special subs. They nest and get localized like s

Re: RFC 284 (v1) Change C<$SIG{__WARN__}> and C<$SIG{__DIE__}> to magic subs

> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes: >> It sounds really stoopid to say C<$SIG{__WARN__}> on a machine which >> doesn't have signals. NW> Indeed. It is also worth noting that people on -flow have been hashing NW> out safe signals through a "use signal" pragma, which wou

Re: RFC 264 (v2) Provide a standard module to simplify the creation of source filters

On Mon, Sep 25, 2000 at 06:37:58PM -, Perl6 RFC Librarian wrote: > This RFC proposes that the interface to Perl's source filtering facilities > be made much easier to use. Hm. I've just sent in the "line disciplines" RFC, which probably will end up obsoleting a reasonable chunk of this. --

RFC 271 (v2) Subroutines : Pre- and post- handlers for subroutines

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Subroutines : Pre- and post- handlers for subroutines =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 21 Sep 2000 Last Modified: 25 Sep 2000 Mailing List: [EMAIL PROTECTED] Numb

RFC 264 (v2) Provide a standard module to simplify the creation of source filters

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Provide a standard module to simplify the creation of source filters =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 20 Sep 2000 Last Modified: 25 Sep 2000 Mailing List: [EMAIL PR

RFC 259 (v3) Builtins : Make use of hashref context for garrulous builtins

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Builtins : Make use of hashref context for garrulous builtins =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 19 Sep 2000 Last Updated: 25 Sep 2000 Mailing List: [EMAIL PROTECTED]

RFC 255 (v3) Fix iteration of nested hashes

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Fix iteration of nested hashes =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 18 Sep 2000 Last Modified: 25 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 255 Version: 3

RFC 223 (v2) Objects: C pragma

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Objects: C pragma =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 14 Sep 2000 Last Modified: 25 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 223 Version: 2 Status: Froze

RFC 55 (v3) Compilation: Remove requirement for final true value in require-d and do-ed files

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 Aug 2000 Last Modified: 25 Sep 2000 Mailing Lis

Re: RFC 284 (v1) Change C<$SIG{__WARN__}> and C<$SIG{__DIE__}> to magic subs

On Mon, Sep 25, 2000 at 11:10:04AM -0700, Nathan Wiger wrote: > Indeed. It is also worth noting that people on -flow have been hashing > out safe signals through a "use signal" pragma, which would remove %SIG > altogether. Oh, well, OK. Then this RFC's necessary, dammit! :) > I like it! But I'm

Re: RFC 284 (v1) Change C<$SIG{__WARN__}> and C<$SIG{__DIE__}> to magic subs

> It sounds really stoopid to say C<$SIG{__WARN__}> on a machine which > doesn't have signals. Indeed. It is also worth noting that people on -flow have been hashing out safe signals through a "use signal" pragma, which would remove %SIG altogether. > Instead, let's implement them as magic subr

Re: RFC 288 (v1) First-Class CGI Support

On Sun, 24 Sep 2000, Nathan Wiger wrote: > > Offer simple functions to set HTTP headers (e.g. content type, result codes) > How about %HTTP, which is just flushed on the first line of output? >use cgi; >$HTTP{'Content-type'} = 'text/html'; >print "Hello!"; # flushes %HTTP first

Re: RFC 290 (v1) Remove -X

"John L. Allen" wrote: > > The use of a caret was to prevent decimation of the user's namespace, > vis: > > perl -e 'print -rwx $_' > Can't call method "rwx" on an undefined value at -e line 1. Yeah, but read the error - Perl's parsing that as: [nwiger@matrix:~]$ perl -MO=Depar

Re: RFC 290 (v1) Remove -X

> > > I'd even go so far as to say that the current -X syntax should be > > > _extended_, to allow for multiple tests at once, maybe by way of a > > > leading caret (mnemonic "all"): > > > > > > -^rwx; # $_ is readable, writable and executable > > > > > > ($s

Re: Perl6Storm: Intent to RFC #0101

> if ( all { $_->($file) } \&writable, \&directory ) { ... Is that the PDL C? With the superpositional C it would be: if ( all(\&writable, \&directory)->($file) ) { ... :-) Hm. Maybe C, C, etc. could return objects that equate to a filename *only* if the original predicate is t

Re: RFC 290 (v1) Remove -X

On Mon, 25 Sep 2000, Nathan Wiger wrote: > > I'd even go so far as to say that the current -X syntax should be > > _extended_, to allow for multiple tests at once, maybe by way of a > > leading caret (mnemonic "all"): > > > > -^rwx; # $_ is readable, writable and executable > > > >

Re: RFC 288 (v1) First-Class CGI Support

On Mon 25 Sep, Perl6 RFC Librarian wrote: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > First-Class CGI Support > > Maintainer: Adam Turoff <[EMAIL PROTECTED]> > > To make CGI programming easier, this option/pragma should: > > Turn on ta

Re: RFC 290 (v1) Remove -X

> I'd even go so far as to say that the current -X syntax should be > _extended_, to allow for multiple tests at once, maybe by way of a > leading caret (mnemonic "all"): > > -^rwx; # $_ is readable, writable and executable > > ($size, $mod, $acc, $ichange) = -^sMAC; In fact, yo

Re: RFC 290 (v1) Remove -X

On Mon, 25 Sep 2000, Clayton Scott wrote: > It: > + stacks multiple tests quite cleanly without excess verbiage >(if (-e && -T && -s && -x){...} gets a little tedious especially >if you don't use $_) > + introduces only 1 new keyword ("file" seems bad, but maybe not) > + does not bre

Re: RFC 290 (v1) Remove -X

On Sun, 24 Sep 2000 23:05:45 -0700, Nathan Wiger wrote: >> Perl programmers happy with the -X syntax will need to get used to the >> lengthier replacement. > >Blech. I certainly think that long functions are fine and dandy, but I'd >loathe the day that I'd have to give up my -X stuff. I *love* it

Re: RFC 288 (v1) First-Class CGI Support

> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> All of the other features offered by Lincoln Stein's CGI.pm PRL> should remain, but should not be deeply integrated into Perl6. PRL> Write a very small cgi.pm module that does as little as possible, PRL> probably based o

Re: RFC 290 (v1) Remove -X

Perl6 RFC Librarian wrote: > =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. > is_re

Re: RFC 290 (v1) Remove -X

On 25 Sep 2000, Perl6 RFC Librarian wrote: > =head1 TITLE > > Remove -X > > The prefered mechanism for file tests should be more legible, using > terms like 'readable(FOO)' and 'writeable(FOO)' instead of the > =head1 MIGRATION ISSUES > Perl programmers happy with the -X syntax will need to

Re: RFC 288 (v1) First-Class CGI Support

> =head1 TITLE > > First-Class CGI Support > 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 C pragma. > > To ma

Re: RFC 283 (v1) C in array context should return a histog ram

On Mon, 25 Sep 2000 14:44:16 +0100, Simon Cozens wrote: >Incidentally, so what if a hash is slow? You pay for what you get. It's still >quicker than doing it by hand. This is for the cases where epeople forget that they are "asking" for it. I don't want comp.lang.perl.misc or any other support c

Re: RFC 283 (v1) C in array context should return a histogram

On Mon, Sep 25, 2000 at 01:55:10PM +0100, Richard Proctor wrote: > It does not seem to have much to do with tr///, if you want it, why not put it > in a module with some meaningful name such as histogram()? Hm. Counting doesn't have much to do with tr///, if you think of it like that. Now, if y

Re: Perl6Storm: Intent to RFC #0101

Nathan Wiger wrote: > In fact, I'd much rather still a more generic function like 'want' that > takes a list of things to check: > >file($file, 'd'); # is it a directory? >file($file, 'wd'); # is it a writable directory? if ( all { $_->($file) } \&writable, \&directory ) { ...

Re: Perl6Storm: Intent to RFC #0004

Adam Turoff wrote: > I plan to offer a more formal RFC of this idea. > > =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. Note that this functionality is trivial if RFC79 is imp

Re: RFC 290 (v1) Remove -X

On Mon, Sep 25, 2000 at 06:02:51AM -, Perl6 RFC Librarian wrote: > =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

Re: RFC 283 (v1) C in array context should return a histogram

Simon, > I think I said in the RFC, didn't I? It's extending the counting use of tr/// > to allow you to count several different letters at once. For instance, letter > frequencies in text is an important metric for linguists, codebreakers and > others; think about how you'd get letter frequenc

Re: RFC 283 (v1) C in array context should return a histog ram

On Mon, Sep 25, 2000 at 03:30:47PM +0200, Bart Lateur wrote: > If you can garantee that it's also not using a hash internally to keep > count, but instead a table parallel to the table that's being used to > hold the conversion values, you've won me over. Naturally, it's hard to guarantee anythin

Re: RFC 287 (v1) Improve Perl Persistance

> Many mechanisms exist to make perl code and data persistant. They should > be cleaned up, unified, and documented widely within the core > documentation. > But doesn't this go against TMTOWTDI. :) Different people might have different requirements. Portability would want all ASCII, large app

Re: RFC 283 (v1) C in array context should return a histog ram

On 25 Sep 2000 06:07:01 -0700, Randal L. Schwartz wrote: >Bart> Plus, in Perl 5, NO core function returns a hash. >Bart> None at all. > >It's not returning a hash. I like the proposal that has it return a >paired list, similar to the semi-paired list we get with a capturing >split, or a list-con

Re: RFC 283 (v1) C in array context should return a histog ram

On Mon, Sep 25, 2000 at 06:07:01AM -0700, Randal L. Schwartz wrote: > Bart> character it finds. Plus, in Perl 5, NO core function returns a hash. > Bart> None at all. > > It's not returning a hash. Precisely. There ain't no such thing as "hash context". It simply returns a list with an even num

Re: RFC 283 (v1) C in array context should return a histog ram

> "Bart" == Bart Lateur <[EMAIL PROTECTED]> writes: Bart> On Mon, 25 Sep 2000 13:00:58 +0200, Henrik Tougaard wrote: >> Are the counts stuffed in the array in the order they appear in the >> tr-string? or in ascii-order? or whatever? Bart> In the same order as they are in the tr/// string, o

Re: RFC 283 (v1) C in array context should return a histog ram

On Mon, 25 Sep 2000 13:00:58 +0200, Henrik Tougaard wrote: >Are the counts stuffed in the array in the order they appear in the >tr-string? or in ascii-order? or whatever? In the same order as they are in the tr/// string, of course. @freq{'a' .. 'z', '0' .. '9'} = tr/a-z0-9//; That j

proposed RFC. lindex() function...

Anyone want to pick up this? I just don't have the time, but I would like to see it in Perl6. = =head1 TITLE Builtin list context lindex() function =head1 VERSION Maintainer: NA <[EMAIL PROTECTED]> Date: 09 SEP 2000 Version: 0 Mailing List: perl6-language Numb

RE: RFC 283 (v1) C in array context should return a histogram

> From: Bart Lateur [mailto:[EMAIL PROTECTED]] > On Mon, 25 Sep 2000 10:19:05 +0100, Simon Cozens wrote: > > >(%alphabet) = $string =~ tr/a-z//; > > > >Yum. > > You want it in a hash? Ooff. Well, maybe that's ok for Perl6. > > For Perl5, it would seem to make more sense, to me, to return

Re: RFC 288 (v1) First-Class CGI Support

Perl6 RFC Librarian wrote: > > =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: > >

Re: RFC 283 (v1) C in array context should return a histogram

On Mon, 25 Sep 2000 10:19:05 +0100, Simon Cozens wrote: >(%alphabet) = $string =~ tr/a-z//; > >Yum. You want it in a hash? Ooff. Well, maybe that's ok for Perl6. For Perl5, it would seem to make more sense, to me, to return a list. Simply a matter of consistency with the spirit of the rest

Re: RFC 283 (v1) C in array context should return a histogram

On Mon, Sep 25, 2000 at 09:55:38AM +0100, Richard Proctor wrote: > While this may be a fun thing to do - why? what is the application? I think I said in the RFC, didn't I? It's extending the counting use of tr/// to allow you to count several different letters at once. For instance, letter frequ

Re: RFC 283 (v1) C in array context should return a histogram

Simon, > 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. While this may be a fun thing to do - why? what is the application? Richard

Re: RFC 255 (v2) Fix iteration of nested hashes

On Mon, 25 Sep 2000 17:18:56 +1100 (EST), Damian Conway wrote: >Since no-one has put their hand up to take this RFC over, I am now >intending to retract it. I simply don't have the time to try and >find a solution to the many (valid) problems that have been pointed out. > >I would heartily encour

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

Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Perl should not abort when a required file yields a false value We had this RFC from Damian already didn't we? -- Piers

Re: RFC 282 (v1) Open-ended slices

On Mon, Sep 25, 2000 at 06:33:07PM +1100, Jeremy Howard wrote: > Can we extend RFC 282 so that it allows the right operand of C<..> to be > omitted in any index, since the upper-bound can be implied? Or does it > already propose this? Yes, I wanted this to apply to all slices. > (...in which cas

Re: RFC 288 (v1) First-Class CGI Support

* Greg Boug ([EMAIL PROTECTED]) [25 Sep 2000 17:46]: [...] > > The RFC should just be a little more specific on what's being > > included and not included. Are any of the functions like header(), > > h2(), footer()? What about %ENV manipulation functions? What do > > people think? > I think that

Re: RFC 282 (v1) Open-ended slices

> =head1 TITLE > > Open-ended slices > <...> > > @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 ins

Re: RFC 288 (v1) First-Class CGI Support

On 25 Sep 2000, Perl6 RFC Librarian wrote: > =head1 TITLE > > First-Class CGI Support First-class CGI to me means HTML::Embperl. It include a templating lanaguage for creating HTML/XML pages and support for session management via cookies. Are we talking about having cookes close to the core?