Re: RFC 105 (v1) Downgrade or remove "In string @ must be \@"error

[David L. Nicol]

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

[Kai Henningsen]

[EMAIL PROTECTED] (Nathan Wiger)  wrote on 15.08.00 in 
<[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.

Uninitialized != doesn't exist. Not arguing for or against the RFC, just  
pointing out the difference.

MfG Kai

Re: RFC 105 (v1) Downgrade or remove "In string @ must be \@" error

[Mark-Jason Dominus]

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 I 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
C if you don't backslash the C<@>.

See L 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

[Nathan Wiger]

"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

[Nathan Torkington]

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

Re: RFC 105 (v1) Downgrade or remove "In string @ must be \@" error

[Chaim Frenkel]

> "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 FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

Re: RFC 105 (v1) Downgrade or remove "In string @ must be \@"error

[Glenn Linderman]

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

[Peter Scott]

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

[Michael Fowler]

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

[Randal L. Schwartz]

> "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]> 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

[Nathan Wiger]

> 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

[John Porter]

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

[Jonathan Scott Duff]

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]

Thus it was written in the epistle of Perl6 RFC Librarian,
> 
> This is something that was put in to catch Perl 4 to Perl 5 migration.
> Perl 6 shouldn't need it, and should just assume that "@wiger" is an
> array, even if it's unitialized. This is what it does for all the other
> data types.

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.

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
It is the first duty of a hypothesis to be intelligible.
-- Huxley, Thomas Henry (1825-1895)
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

RFC 105 (v1) Downgrade or remove "In string @ must be \@" error

[Perl6 RFC Librarian]

This and other RFCs are available on the web at
  http://dev.perl.org/rfc/

=head1 TITLE

Downgrade or remove "In string @ must be \@" error

=head1 VERSION

   Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
   Date: 15 Aug 2000
   Version: 1
   Mailing List: [EMAIL PROTECTED]
   Number: 105
   Status: Developing

=head1 ABSTRACT

Currently, if you write:

   $email = "[EMAIL PROTECTED]";

You get a B error:

   In string, @wiger now must be written as \@wiger

This should be a warning or removed altogether in Perl 6.

=head1 DESCRIPTION

This is something that was put in to catch Perl 4 to Perl 5 migration.
Perl 6 shouldn't need it, and should just assume that "@wiger" is an
array, even if it's unitialized. This is what it does for all the other
data types.

Either that, or catch all the unused occurrences of %, $, @, and so on.
For example, neither of these creates a fatal error (or even a warning):

   $email = "nate$wiger.org";
   $email = "nate%wiger.org";

=head1 IMPLEMENTATION

Downgrade the error to a warning. Even better, remove the warning
altogether. Perl 5's been out for years.

=head1 REFERENCES

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-07/msg02150.html