RE: purge: opposite of grep

> FWIW, I came up with "purge" because my first inclination was to spell > "grep" backwards: "perg". :-) I like "purge", although "except", "exclude", and "omit" all have their charms. For partition function, I like "divvy", "carve", "segment" (in that order) and almost anything other than "sepa

RE: RFC - Hashing PMC's

> But then sometimes you'd *want* hashing to be based on the > content. OK, I'll bite -- when would you want this behavior? This behavior means that once you change the contents, the hash value would become irretrievable unless you restored the contents of the key. (Is this useful in functional

RE: RFC - Hashing PMC's

As the last person to change the key hash algorithm, I'd like to chime in here with a request that each PMC provide a string that the key hashing algorithm can operate on. To some degree this is just selfish on my part -- I've got plans for upgrading the key hash algorithm in Perl 5 and Perl 6 wh

RE: Selective exporting of properties/methods

Miko O'Sullivan writes: >What I've often wanted would be standard method that is called before every >subroutine call. If that method returns false then the method that was >called is not called. What you're describing is Aspect-Oriented Programming (I think). Take a look around CPAN for Aspect.

RE: quote for the day

> >What is this talk of software 'releases'? Klingons do not > 'release' software; > >our software ESCAPES, leaving a bloody trail of designers and quality > >assurance people in its wake! One good source of all the Klingon programmer sayings: http://public.logica.com/~stepneys/joke/kli

RE: RFC 329 (v1) C

>I briefly considered > >{ >use syntax "python"; >} > >and nearly lost my lunch. And if you want to lose your breakfast too, consider: use "lisp"; use "apl"; (Although if the array-processing and currying RFCs are accepted, Perl will finally have powers beyond tho

RE: PERL6STORM - tchrist's brainstorm list for perl6

> =item perl6storm #0064 > > Do something about microsoft's CRLF abomination. I think for the case of Microsoft C++ used for the Win32 port, everyone would be happy if Perl's sysopen, sysread, etc. did not require binmode. Unfortunately, Microsoft made the decision very early on in its C/C++ dev

RE: RFC 176 (v1) subroutine / generic entity documentation

> #File: Foo.pm > sub foo : doc( In:scalar - int - foo identifier >Out:array - decomposed foo >Effects: Queries Foo DB >Exceptions: DBI, "bad foo id" > EOS > { This is an interesting and powerful idea, but I can't help thinking that it needs to be

RE: Do we really need eq?

Al Lipscomb writes: >I was wondering about maybe being able to store these > attributes as > optional parts of the scalar. Something like this (please > don't get hung up > on the details, I am not much of a designer): > >my($amt,$hours,$total); >$amt->{TYPE} = "DOLLARS"; >$total->{

RE: RFC 168 (v1) Built-in functions should be functions

John Porter writes: > Ah, the old "If you want Tcl, you know where to find it" non-argument. > > "Closures?""No! This is Perl, not Lisp!" > "Objects?" "No! This is Perl, not Smalltalk!" > "Patterns?""No! This is Perl, not Snobol!" > "Subroutines?" "No! This is Perl, not Basic!" >

RE: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.

>By the way, for all you thesis writers and thesis advisors out there -- I >suspect that a separate implementation of the Perl6 lexer and/or Perl6 >parser might make a dandy thesis topic... By the way, this message makes more sense if you s/a separate/an independent/... :( > =

RE: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.

> > Do we have an RFC yet that proposes Perl to be easier parsable? > > Damian? > >Working on it. By the way, for all you thesis writers and thesis advisors out there -- I suspect that a separate implementation of the Perl6 lexer and/or Perl6 parser might make a dandy thesis topic... ===

RE: RFC 29 (v1) unlink() should be left alone

> 5. Other operating systems/ file systems have, or could have > hypothetically, the same operation. I.e. just because NTFS > doesn't have multiple links now (or does it?) doesn't mean > it won't in the future. NTFS does support hard links right out of the box, although the firs