User-defined quoting operators

A while ago on p5p Joseph Hall allowed as how he would like to have core support for SQL via a construct like qs/SELECT * FROM s_emp WHERE empno IN (101, 343, 573)/ I suggested that one would need to know what database handle it was acting on, and that what made sense (to me) was to ov

Re: RFC 111 (v1) Whitespace and Here Docs

> I was sorta going under the assumption that <<< would cause leading and > trailing whitespace to be ignored (not stripped) when looking for the > end-of-here-doc indicator. Because whitespace is ignored, I was then > proposing some new syntax for stripping whatever one likes from the contents >

Re: RFC 111 (v1) Whitespace and Here Docs

>Unfortunately the quoting on the terminator following << decides the type >of interpolation; we're missing a way of indicating how to recognize the >terminator other than an exact match. If we say that we want varia

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

Bart Lateur writes: > Oh. I would have put my hopes on a better (= more generic) O::Deparse > mechanism to make Perl analyse the source code for you. Rewriting a Perl > in a module seems a bit silly to me. I don't know enough swear words to say how much I fucking hate the stupid braindead dumbfuc

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

Dan Sugalski writes: > Personally I think I'm in favor of Nat's suggestion of allowing the > definition of new infix operators and let this be taken care of in a > module, but that's just passing the buck. (Not that it's a bad strategy, > mind... :) Solve the generic problem, not a specific on

Re: RFC 147 (v1) Split Scalars and Objects/References into Two Types

Tom Christiansen wrote: > > Perl already does the sanity check for you: "can't call method > without package or reference". What you're saying requires the > programmer to diddle about, which is never a win. I'll concede that point, with the counter that it lets you get exactly what you want. C

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

On Thu, 24 Aug 2000, Nathan Torkington wrote: > You'd obviously want to have a module that collected together your > favourite new operators. But if they were lexically scoped, they'd > be lexically scoped to the module they were defined in, i.e. your > collection rather than your main program.

Re: RFC 111 (v1) Whitespace and Here Docs

On Thu, Aug 24, 2000 at 05:24:14PM -0700, Peter Scott wrote: > At 05:41 PM 8/24/00 -0600, Tom Christiansen wrote: > >But you don't need that when you can and possibly should just write this: > > > > print <<"EOF" =~ /^\s*\| ?(.*\n)/g; > > Others may be focussing on th

Re: RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@>

At 01:32 AM 8/25/00 +0200, Bart Lateur wrote: >On Thu, 24 Aug 2000 13:50:56 -0700, Peter Scott wrote: > >Yes, this is losing information; the former $! is no longer around. I > >contend that it's eliding functionality that is seldom, if ever, used, in > >favor of a natural simplification. There'

Re: RFC 111 (v1) Whitespace and Here Docs

On Thu, Aug 24, 2000 at 05:41:00PM -0600, Tom Christiansen wrote: > But you don't need that when you can and possibly should just write this: > > print <<"EOF" =~ /^\s*\| ?(.*\n)/g; > | Attention criminal slacker, we have yet > | to receive payment for our legal services.

Re: RFC 111 (v1) Whitespace and Here Docs

At 05:41 PM 8/24/00 -0600, Tom Christiansen wrote: >But you don't need that when you can and possibly should just write this: > > print <<"EOF" =~ /^\s*\| ?(.*\n)/g; > | Attention criminal slacker, we have yet > | to receive payment for our legal s

Re: RFC 127 (v1) Sane resolution to large function returns

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> At 02:25 PM 8/24/00 -0400, Chaim Frenkel wrote: >> But >> >> ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) >> >> Actually, looking at it like that makes it an ugly situation. The 'new' >> expectation would be to have it

Re: RFC 147 (v1) Split Scalars and Objects/References into Two Types

On 24 Aug 2000 15:53:42 -, Perl6 RFC Librarian wrote: >Everyone on this list should be familiar with the problem. You can't >tell scalars and references apart by looking at them. They are >completely ambiguous. Consider: > > $stuff{key} # hash value > $stuff[0]# array value

Re: RFC 111 (v1) Whitespace and Here Docs

>Basically, it's shorthand for the current syntax: >$message = <<"EOF" =~ s/^\s*\| ?//g; >| Attention criminal slacker, we have yet >| to receive payment for our legal services. >| >| Love and kisses >| >EOF >print $message; >But any i

Re: RFC 111 (v1) Whitespace and Here Docs

On Thu, Aug 24, 2000 at 05:26:36PM -0600, Tom Christiansen wrote: > >I thought this problem would've been neatly solved by my proposed: > > >print <<<"FOO" =~ s/^ {8}//; > >Attention criminal slacker, we have yet > >to receive payment for our legal services. > > >

Re: RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@>

On Thu, 24 Aug 2000 13:50:56 -0700, Peter Scott wrote: >>But $@ is an entirley different beast. >The proposal is that $! would be overwritten with the die string. Reason: >whoever's interested in both $@ and $! at the end of an eval? There was an >error; everyone looks at $@, which almost c

Re: RFC 111 (v1) Whitespace and Here Docs

>I thought this problem would've been neatly solved by my proposed: >print <<<"FOO" =~ s/^ {8}//; >Attention criminal slacker, we have yet >to receive payment for our legal services. >Love and kisses >FOO The result of substituting the leading 8 bla

Re: RFC 111 (v1) Whitespace and Here Docs

>Today around 4:30pm, Tom Christiansen hammered out this masterpiece: >: print print <<" FOO" =~ /^\s+(.*\n)/gm; >Unless, of course, you want `xx oo' to be indented still, and the blank >remain. That r

Re: RFC 111 (v1) Whitespace and Here Docs

On Thu, Aug 24, 2000 at 06:14:10PM -0400, Michael G Schwern wrote: > Paragraphs. > > sub legal { > print << Attention criminal slacker, we have yet > to receive payment for our legal services. > > Love and kisses > FOO > } > > Obvi

Re: RFC 111 (v1) Whitespace and Here Docs

Today around 4:30pm, Tom Christiansen hammered out this masterpiece: : print <'[EMAIL PROTECTED]',site=> 'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig->{site})+6),"\n"; print map{$_.': '.$sig->{$_}."\n"}sort{$sig->{$a}cmp$sig->{$b}}keys%{$sig}; my $VERSION = '0.01'; #'patche

Re: RFC 147 (v1) Split Scalars and Objects/References into Two Types

Tom Christiansen wrote: > > I happen to strongly appreciate that the invocant in > > $a->blah > > can be of either sort; that is: > > $a = "MyClass"; > $a->blah; > > or > > $a = MyClass->generate(); > $a->blah(); > > In fact, who knows what generate() returned? It could

Re: RFC 111 (v1) Whitespace and Here Docs

At 04:30 PM 8/24/00 -0600, Tom Christiansen wrote: > >I'm coming into this a bit late, so forgive me if this is impossible or > >already dismissed, but what about > > > print < > Attention, dropsied weasel, we are > > launching our team of legal beagles > >

Re: RFC 111 (v1) Whitespace and Here Docs

>I'm coming into this a bit late, so forgive me if this is impossible or >already dismissed, but what about > print < Attention, dropsied weasel, we are > launching our team of legal beagles > straight for your scrofulous crotch. >

Re: RFC 147 (v1) Split Scalars and Objects/References into Two Types

>However, consider this in a different light for a moment: > $a = "MyClass"; > *a = MyClass->generate; # ask for ref back > $a->blah; > *a->blah; # use our ref >Whether or not having to care about your refs is good or bad depends on >which way you look at it. In one cas

Re: RFC 111 (v1) Whitespace and Here Docs

At 06:14 PM 8/24/00 -0400, Michael G Schwern wrote: >Okay, devil's advocate. > >Paragraphs. > > sub legal { > print << Attention criminal slacker, we have yet > to receive payment for our legal services. > > Love and kisses > FOO > }

Re: RFC 111 (v1) Whitespace and Here Docs

Okay, devil's advocate. Paragraphs. sub legal { print <

Re: RFC 147 (v1) Split Scalars and Objects/References into Two Types

Tom Christiansen wrote: > > You pretend that a reference is not a "true" scalar. > That's certainly not valid. It obviously is. Well, this is a matter of semantics, pure and simple. Technically, it is. But I would argue that cognitively it is not by any means. Especially if a reference points t

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

At 02:09 PM 8/24/00 -0400, John Porter wrote: >Markus Peter wrote: > > > > Another possibility would be to use cmpi and eqi > >Actually, all we need is cmpi, since eqi is just !cmpi. >(And eq is !cmp.) Nope. Read the manual. --- Ma

Re: RFC 157 (v1) Delete C and C commands.

On Thu, Aug 24, 2000 at 08:29:21PM -, Perl6 RFC Librarian wrote: > The C and C commands are legacy commands which have been > deprecated for at least 5 years. They should be removed from the language. Two nit picks. First, dbmopen() isn't deprecated. [This function has been largely sup

Re: RFC 156 (v1) Replace first match function (C) with a flag to the match command.

Bart Lateur wrote: > > And, what's so special about the first match? What if I want the second > match, or the third? (/foo/g)[2] ??? -- John Porter We're building the house of the future together.

Re: RFC 156 (v1) Replace first match function (C) with a flag to the match command.

On 24 Aug 2000 20:29:21 -, Perl6 RFC Librarian wrote: >Replace first match function (C) with a flag to the match command. Sounds reasonable. I propose "1". ?foo? becomes /foo/1 Eh, no, that looks silly. And, what's so special about the first match? What i

Re: RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@>

At 10:37 PM 8/24/00 +0200, Bart Lateur wrote: >On 24 Aug 2000 16:03:56 -, Perl6 RFC Librarian wrote: > > >Merge C<$!>, C<$^E>, and C<$@> > >Merging $! and $^E makes perfect sense to me. I don't know why there are >two different error variables. $! eq "No such file or directory"; $^E eq "CD-R

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

On 24 Aug 2000 20:24:52 -, Perl6 RFC Librarian wrote: >Damian Conway's Text::Balanced module does a pretty good job of >tokenizing Perl code. However, bare C and C require >semantic analyis to distinguish them from division and the hook >(C) operator. > >To remove this hassle, and thus permi

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

Bart Lateur wrote: > > Suppose you want to keep the case on the hash keys, because you > enumerate them. But you still want to find hash entries in a case > insensitive manner... ...then you simply reach for Tie::CPHash on CPAN! -- John Porter

Re: RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@>

On 24 Aug 2000 16:03:56 -, Perl6 RFC Librarian wrote: >Merge C<$!>, C<$^E>, and C<$@> Merging $! and $^E makes perfect sense to me. I don't know why there are two different error variables. Er... wasn't that three? I'm not absolutely certain, but I thought there was a third one, too. Oh yes

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

On Thu, Aug 24, 2000 at 10:28:51PM +0200, Bart Lateur wrote: > On 24 Aug 2000 15:40:00 -, Perl6 RFC Librarian wrote: > > >Perl currently only has C and C operators which work case-sensitively. > >It would be a useful addition to add case-insensitive equivalents. > > Next you'll want case)ins

RFC 157 (v1) Delete C and C commands.

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Delete C and C commands. =head1 VERSION Maintainer: Stephen P. Potter <[EMAIL PROTECTED]> Date: Aug 24 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 157 =head1 ABSTRACT The C and C com

RFC 156 (v1) Replace first match function (C) with a flag to the match command.

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Replace first match function (C) with a flag to the match command. =head1 VERSION Maintainer: Stephen P. Potter <[EMAIL PROTECTED]> Date: Aug 24 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Num

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

On 24 Aug 2000 15:40:00 -, Perl6 RFC Librarian wrote: >Perl currently only has C and C operators which work case-sensitively. >It would be a useful addition to add case-insensitive equivalents. Next you'll want case)insensitive hashes! Er... actually, that sounds rather useful, even more tha

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

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Require explicit m on matches, even with ?? and // as delimiters. =head1 VERSION Maintainer: Nathan Torkington <[EMAIL PROTECTED]> Date: August 20, 2000 Last Modified: August 24, 2000 Version: 2 M

Re: OT: pronouncing "www" (was: Re: ... as a term)

Thus it was written in the epistle of Austin Hastings, > "foo.bar" ne "www.foo.bar" > > pronounce("foo.bar") eq pronounce("www.foo.bar") > > As in, "Surf to www.perl.org and read the new ..." > > sounds like > > "Surf to perl dot org and read the new ..." > > =Austin Just to be absolutely ce

Re: RFC 127 (v1) Sane resolution to large function returns

Chaim Frenkel wrote: > ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) > > Actually, looking at it like that makes it an ugly situation. The 'new' > expectation would be to have it become > # $foo=1 $baz=2 @bar=(4) Actually? How about it becoming

Re: OT: pronouncing "www" (was: Re: ... as a term)

"foo.bar" ne "www.foo.bar" pronounce("foo.bar") eq pronounce("www.foo.bar") As in, "Surf to www.perl.org and read the new ..." sounds like "Surf to perl dot org and read the new ..." =Austin --- Tom Christiansen <[EMAIL PROTECTED]> wrote: > >The "www" in e.g., "www.netscape.com" is pronounce

Re: RFC 127 (v1) Sane resolution to large function returns

Dan Sugalski <[EMAIL PROTECTED]> writes: >At 02:25 PM 8/24/00 -0400, Chaim Frenkel wrote: >>But >> >>($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) >> >>Actually, looking at it like that makes it an ugly situation. The 'new' >>expectation would be to have it become >>

Re: Exception handling [Was: Re: Things to remove]

"BSOD" => huh? Oh, Blue Screen of Death. Certainly if the OS doesn't support trapping an error, then the language running on it cannot either. But if the OS does, then the language could. If the language could, then the question remains whether it should, and that's a -language topic that hasn

Re: RFC 127 (v1) Sane resolution to large function returns

At 02:25 PM 8/24/00 -0400, Chaim Frenkel wrote: >But > >($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) > >Actually, looking at it like that makes it an ugly situation. The 'new' >expectation would be to have it become > # $foo=1 $baz=2 @bar=(4) Woul

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

At 11:33 AM 8/24/00 -0600, Tom Christiansen wrote: > >While I don't know that I'd argue in favor of this feature request, your > >argument against misses the mark here. It's saying, essentially, that the > >difference between "P" and "p" is the same as the difference between -1 and > >1. That, as

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

Yes, these all sound useful! Damian, could you make sure they get included in your switch statement? And don't forget =:= which should compare lazy, infinite sublists, as in if ( 4..:2 =:= 2 * ( 2.. )) { ... } Jarkko Hietaniemi wrote: > I want four special new comparison operator

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

Markus Peter wrote: > > Another possibility would be to use cmpi and eqi Actually, all we need is cmpi, since eqi is just !cmpi. (And eq is !cmp.) -- John Porter if ( abs($a cmp $b) cmp abs($b cmp $a) ) ...

Re: RFC 127 (v1) Sane resolution to large function returns

I'm missing what you are trying to say. Are you suggesting that $foo = @bar no longer mean ($foo = scalar(@bar)) == 3 ? I wasn't suggesting going that far. Just a little more DWIM. So that ($foo, @bar, $baz) = (1,2,3) # $foo = 1 @bar=(2,3), $baz = undef # o

Upscope (was Re: RFC 143)

Nathan Torkington wrote: > > We're going to have to > think of a way to consistently say "do this in my caller's lexical > scope" without it becoming a nasty upvar hell. Perhaps this would work: a way to override (i.e. quash) the behavior that instantiates a new scope on entry to a lexical bloc

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

We need a way to mix eq, the things to be compared, and the operation to be done on them before they are compared: lc{ $foo eq $bar } $foo eq (lc) $bar $foo eq{lc} $bar None of those are like any existing syntax in Perl. The current way: lc($foo) eq lc($bar) seems fine in compari

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

>In my consideration, a >case-insensitive equality check is a rather common operation in Perl >programs so it deserves its own operator. That doesn't folllow. We already have a trivial and very obvious way of doing it that doesn't require that any one learn anything new that they don't already

Re: OT: pronouncing "www"

At our company, we pronounce "www" as "dub-dub-dub". The first syllable of the letter "w", three times. Very easy to say quickly. "dub-dub-dub-dot-perl-dot-com". Try it. -- Eric J. Roode, [EMAIL PROTECTED] print

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

>While I don't know that I'd argue in favor of this feature request, your >argument against misses the mark here. It's saying, essentially, that the >difference between "P" and "p" is the same as the difference between -1 and >1. That, as they say, turns out not to be the case. >The upper and

Re: OT: pronouncing "www" (was: Re: ... as a term)

>The "www" in e.g., "www.netscape.com" is pronounced, IMO, in >the same way as other useless, should-be-obvious punctuation. >It's silent. Seems like something you should take up with RFC 819, or maybe with RFC 881, considering that they and their ramifying successors all seem to be in flagrant

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

--On 24.08.2000 10:56 Uhr -0600 Tom Christiansen wrote: >> The probably worst about these statements is that they look ugly. > > To the contrary: in the case (ahem) of the application of lc() on > the comparison's operand, they look especially beautiful. Depends on taste I guess... > >> Also,

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

I want four special new comparison operators. Firstly, " e q " That is, an operator that ignores any leading, any trailing, and treats all intraspace as equivalent. If the embedded space is confusing, I may consider suggesting an operator modifier, "/ ". Secondly, Eq, which

Re: RFC 147 (v1) Split Scalars and Objects/References into Two Types

>Split Scalars and Objects/References into Two Types I do not see how taking something simple and elegant and making it complicated does anybody any good. And yes, I did read all of it. You pretend that a reference is not a "true" scalar. That's certainly not valid. It obviously is. You als

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

At 10:56 AM 8/24/00 -0600, Tom Christiansen wrote: > >Also, > >they further complicate statements and they are counter-intuitive for > >beginners - why should I change the case of variables if I only want > >to compare them? > >Again, I reach the contrary conclusion: they say exactly what they >ar

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

>Case ignoring eq and cmp operators >=head2 Problems with current ways to do it >Perl currently knows basically two methods for checking of equality of >strings case-insensitively: > uc($a) eq uc($b) > $a =~ /^$b$/i >and for comparing them one: > uc($a) cmp uc($b) >The probably worst about t

Re: RFC 143 (v1) 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. I think this is an excellent idea. I personally would find it very useful. > $a eq/i $b > $a cmp/i $b > >This still leaves some room for future additi

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

On Thu, Aug 24, 2000 at 03:40:00PM -, Perl6 RFC Librarian wrote: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Case ignoring eq and cmp operators > > =head1 VERSION > > Maintainer: Markus Peter <[EMAIL PROTECTED]> > Date: 24 Aug 200

Re: OT: pronouncing "www" (was: Re: ... as a term)

The "www" in e.g., "www.netscape.com" is pronounced, IMO, in the same way as other useless, should-be-obvious punctuation. It's silent. --- Dave Storrs <[EMAIL PROTECTED]> wrote: > > > On Thu, 24 Aug 2000, Bart Lateur wrote: > > On Mon, 21 Aug 2000 18:21:00 -0700 (PDT), Larry Wall wrote: >

Re: RFC 127 (v1) Sane resolution to large function returns

Chaim Frenkel writes: : LW> P.S. I think we *could* let @foo and %bar return an object ref in scalar : LW> context, as long as the object returned overloads itself to behave as : LW> arrays and hashes currently do in scalar context. : : Isn't this an internals issue? Not completely. The scalar

RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@>

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Merge C<$!>, C<$^E>, and C<$@> =head1 VERSION Maintainer: Peter Scott <[EMAIL PROTECTED]> Date: 24 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 151 =head1 ABSTRACT Th

OT: pronouncing "www" (was: Re: ... as a term)

On Thu, 24 Aug 2000, Bart Lateur wrote: > On Mon, 21 Aug 2000 18:21:00 -0700 (PDT), Larry Wall wrote: > >If you want to save the world, come up with a better way to say "www". > >(And make it stick...) > > "The world"? This problem only exists in English! > > We pronounce it something similar

RFC 147 (v1) Split Scalars and Objects/References into Two Types

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Split Scalars and Objects/References into Two Types =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 23 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 147 Sta

Re: RFC 127 (v1) Sane resolution to large function returns

> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> Dan Sugalski writes: LW> : And do we want to consider making this (and its ilk) Do The Right Thing? LW> : LW> :(@foo, @bar) = (@bar, @foo); LW> We certainly want to consider it, though perhaps not in -internals. LW> You can talk about

RFC 143 (v1) Case ignoring eq and cmp operators

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Case ignoring eq and cmp operators =head1 VERSION Maintainer: Markus Peter <[EMAIL PROTECTED]> Date: 24 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 143 =head1 ABSTRACT Perl curre

Re: RFC 133 (v1) Alternate Syntax for variable names

Michael Maraist wrote: > > > my var; # declaring a scalar > > my array[]; # declaring an array > > my hash{}; # declaring a hash > > Though the declarations seem fine, I assume that you propose this to be > optional at usage time, since variable interpolations such as > "xxx${var1}xxx${var

Re: [OT] How to pronounce 'www' (was Re: ... as a term)

On Wed, 23 Aug 2000 20:58:02 -0700, Daniel Chetlin wrote: >I use "dub dub dub", which I picked up at Intel. I find it much easier to >pronounce quickly than anything that uses an approximant. I do like "wibbly". Or "wibble". It ha