Re: RFC 105 (v1) Downgrade or remove In string @ must be \@error
Glenn Linderman wrote: Peter Scott wrote: I have often wished that digraphs were not bundled with variables in this respect, i.e., I wanted to put a string containing \n inside single quotes just 'cuz it didn't contain variables to be interpolated. Whether there's a way of improving this behavior or not I don't know. s/something/somethingelse/ge can get really specific, you can do stuff like only interpolate the ones that are more than 12 -- David Nicol 816.235.1187 [EMAIL PROTECTED] Does despair.com sell a discordian calendar?
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
"Randal L. Schwartz" wrote: What would be NICE is to treat @stonehenge here as *always* a variable So, I'd support a modification to the RFC that does what Larry intended here: array interpolation should work exactly like scalar interpolation That was actually the intent of the RFC, but I'll update v2 to make it clearer. Thanks, Nate
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
This has already been done for Perl 5.6.1. Here is what perldelta.pod has to say. =head2 Arrays now Always Interpolate Into Double-Quoted Strings In double-quoted strings, arrays now interpolate, no matter what. The behavior in perl 5 was that arrays would interpolate into strings if the array had been mentioned before the string was compiled, and otherwise Perl would raise a fatal compile-time error. In versions 5.000 through 5.003, the error was Literal @example now requires backslash In versions 5.004_01 through 5.6.0, the error was In string, @example now must be written as \@example The idea here was to get people into the habit of writing C"fred\@example.com" when they wanted a literal C@ sign, just as they have always written C"Give me back my \$5" when they wanted a literal C$ sign. Starting with 5.6.1, when Perl now sees an C@ sign in a double-quoted string, it Ialways attempts to interpolate an array, regardless of whether or not the array has been used or declared already. The fatal error has been downgraded to an optional warning: Array @example will be interpolated in string This warns you that C"[EMAIL PROTECTED]" is going to turn into Cfred.com if you don't backslash the C@. See Lhttp://www.plover.com/~mjd/perl/at-error.html for more details about the history here. Mark-Jason Dominus [EMAIL PROTECTED] I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
On Tue, Aug 15, 2000 at 04:09:51PM -0400, Ted Ashton wrote: Better yet, DWIM. If I write print "[EMAIL PROTECTED]"; and no array @southern exists, I probably mean I want it to print [EMAIL PROTECTED] I'd say, if the variable exists, interpolate it. If not, print it as it stands. Isn't that the way perl4 did it? I don't know what agony lwall and friends went through that made them change this behaviour though. It would be good for someone who does to speak up about it. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
Ted Ashton wrote: Better yet, DWIM. If I write print "[EMAIL PROTECTED]"; and no array @southern exists, I probably mean I want it to print [EMAIL PROTECTED] I'd say, if the variable exists, interpolate it. If not, print it as it stands. Um, no. Something about the relaxation of strictness in a special context (interpolation) makes me uneasy... -- John Porter
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
Better yet, DWIM. If I write print "[EMAIL PROTECTED]"; and no array @southern exists, I probably mean I want it to print [EMAIL PROTECTED] I'd say, if the variable exists, interpolate it. If not, print it as it stands. I initially was thinking this too, but there's a major problem: print "Your stuff is: @stuff\n"; I want this to *always* print out the _value_ of @stuff, even if it's unititalized. Perl's already smart enough. I think getting in the habit of writing: $email = '[EMAIL PROTECTED]'; Is the better thing to do. -Nate
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
"Jonathan" == Jonathan Scott Duff [EMAIL PROTECTED] writes: Jonathan Isn't that the way perl4 did it? I don't know what agony lwall and Jonathan friends went through that made them change this behaviour though. It Jonathan would be good for someone who does to speak up about it. It permits "action at a distance". A program that originally didn't have @stonehenge in print "email me at [EMAIL PROTECTED]" may someday later introduce a @stonehenge, and now this statement means something completely different. What would be NICE is to treat @stonehenge here as *always* a variable (similar to the way scalars are treated), which was actually implemented in one of the perl5 alphas, but changed to the current behavior when it made too many programs print "merlyn.com" for the above! So, I'd support a modification to the RFC that does what Larry intended here: array interpolation should work exactly like scalar interpolation -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
On Tue, Aug 15, 2000 at 04:09:51PM -0400, Ted Ashton wrote: Better yet, DWIM. If I write print "[EMAIL PROTECTED]"; and no array @southern exists, I probably mean I want it to print [EMAIL PROTECTED] I'd say, if the variable exists, interpolate it. If not, print it as it stands. Some time ago, this is how it was done, to stay backwards compatible. In recent versions (the farthest I can tell is 5.004) it became a fatal error. I don't think we should go backwards. If someone uses @, they mean array. A warning should be emitted, but it should print a blank string. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
At 02:44 PM 8/15/00 -0700, Nathan Wiger wrote: Better yet, DWIM. If I write print "[EMAIL PROTECTED]"; and no array @southern exists, I probably mean I want it to print [EMAIL PROTECTED] I'd say, if the variable exists, interpolate it. If not, print it as it stands. Less DWIM, please. I initially was thinking this too, but there's a major problem: print "Your stuff is: @stuff\n"; I want this to *always* print out the _value_ of @stuff, even if it's unititalized. Arrays aren't uninitialized. They contain zero or more scalars, some of which may be uninitialized. Perl's already smart enough. I think getting in the habit of writing: $email = '[EMAIL PROTECTED]'; Is the better thing to do. Yes! I think of the quotes as: ' - for strings not doing any variable interpolation " - for strings doing interpolation, or including digraphs I have often wished that digraphs were not bundled with variables in this respect, i.e., I wanted to put a string containing \n inside single quotes just 'cuz it didn't contain variables to be interpolated. Whether there's a way of improving this behavior or not I don't know. -- Peter Scott Pacific Systems Design Technologies
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@error
Peter Scott wrote: I have often wished that digraphs were not bundled with variables in this respect, i.e., I wanted to put a string containing \n inside single quotes just 'cuz it didn't contain variables to be interpolated. Whether there's a way of improving this behavior or not I don't know. We could invent qv/interpolate variables/ qd/interpolate digraphs/ qs/interpolate scalars/ qa/interpolate arrays/ qh/interpolate hashes/ qr/intepolate -/ qx/replace with stdout of execution of string as command/ Then, define qvd/same as qq interpolate variables and digraphs/ qvdsahr/interpolate everything/ One possible problem with this solution is that it potentially consumes quite a few symbols that start with q. Maybe it should be: q/interpolate variables/v q/interpolate digraphs/d q/interpolate scalars/s q/interpolate arrays/a q/interpolate hashes/h q/intepolate -/r q/same as qq: interpolate variables and digraphs/vd q/interpolate everything/adhrsv In that case, qq// and qx// should be translated to q/interpolate variables and digraphs/vd q/replace with stdout of execution of string as command/x by p52p6, I suppose. -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne ___ Why pay for something you could get for free? NetZero provides FREE Internet Access and Email http://www.netzero.net/download/index.html
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
"PS" == Peter Scott [EMAIL PROTECTED] writes: I want this to *always* print out the _value_ of @stuff, even if it's unititalized. PS Arrays aren't uninitialized. They contain zero or more scalars, some of PS which may be uninitialized. I don't know if it is still true. But at one point in perl's life defined(@arr) was false before anything was assigned to the array. At this point this is highly frowned upon. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@error
Peter Scott wrote: I have often wished that digraphs were not bundled with variables in this respect, i.e., I wanted to put a string containing \n inside single quotes just 'cuz it didn't contain variables to be interpolated. Whether there's a way of improving this behavior or not I don't know. How odd, I've only very rarely needed this. I don't mind the extra typing in the few situations it has come up. I'd rather the extra typing than YAQO (yet another quoting operator). Nat
