«

Hello,

I was surprised to find out that there seems to be only one assignment
notation that guarantees no interpolation/escape:

#!perl
my $str = <<'EndOfString';
'"\ \$@% \\A $ $r \n \\n \\\B
EndOfString
chomp $str;
print $str;

IMO this is no assignment of a var anymore. It feels more like a trick
box with here-doc and chomp.

But this notation is not very parctical to use in daily work (eg
binaries). Does anyone else have the same experience/suggestions ?

--
Bart

Bart Van der Donck wrote:
> I was surprised to find out that there seems to be only one assignment
> notation that guarantees no interpolation/escape:

Assignments never do any interpolation.

my $foo = "Never want to see this text";
my $x = '$foo\n'; print $x;
my $y = $x; print $y;

Both print() statement print the literal text '$foo\n'. No interpolation
happening, neither when assigning directly from a string nor when assigning
from another variable.
What are you talking about?

> my $str = <<'EndOfString';
> '"\ \$@% \\A $ $r \n \\n \\\B
> EndOfString
> chomp $str;
> print $str;
>
> IMO this is no assignment of a var anymore. It feels more like a trick
> box with here-doc and chomp.

To me it looks like a misguided attempt to solve a perceived problem.

> But this notation is not very parctical to use in daily work (eg
> binaries).

Certainly agree with that evaluation.

> Does anyone else have the same experience/suggestions ?

No. And suggestion for what? You didn't tell us what you are really trying
to do.
Assignments without interpolating the assigned value cannot be the issue
because assignments don't do interpolation anyway.

jue

Jürgen Exner wrote:

> [...]
> Assignments never do any interpolation.

Am I using the wrong terminology ?

my $bar = "a";
my $foo = "bc$bar";

"bc$bar" is the assignment of declaration 'my $foo', right ?
As I understand it, there is an interpolation of the $bar-variable
inside the assignment of $foo, so $foo gets value "bca".

> [...]
> To me it looks like a misguided attempt to solve a perceived
> problem.

The problem is that I want a variable to have the exact value as I
typed it in the code, regardless of which characters I use (assumed,
within the limitations of the OS and of Perl).

> [...]
> And suggestion for what? You didn't tell us what you are
> really trying to do.

One could think of a number of application fields, for example, a
variable that holds the contents of a .gif file. Just any case where
one needs to be sure the typed characters will become the exact value
of the variable under any circumstances.

--
Bart

Bart Van der Donck wrote:
> Jürgen Exner wrote:
>> Assignments never do any interpolation.
> Am I using the wrong terminology ?

Yes.

> my $bar = "a";
> my $foo = "bc$bar";
>
> "bc$bar" is the assignment of declaration 'my $foo', right ?

No. It is a string expression.

> As I understand it, there is an interpolation of the $bar-variable
> inside the assignment of $foo,

That's incorrect.


> so $foo gets value "bca".

If you take 16/64 and cancel the sixes in the numerator and denominator, you get 1/4.
Therefore, 16/64 equals 1/4.


>> To me it looks like a misguided attempt to solve a perceived
>> problem.
>
> The problem is that I want a variable to have the exact value as I
> typed it in the code, regardless of which characters I use (assumed,
> within the limitations of the OS and of Perl).

Do you mean simply no interpolation?

>> And suggestion for what? You didn't tell us what you are
>> really trying to do.
>
> One could think of a number of application fields, for example, a
> variable that holds the contents of a .gif file.

That's outside the limitations of Perl.
You can't put in an arbitrary binary literal in line in your code.
(I don't really know why you want to.)

But as Jue showed you, you can have string literals without interpolation.

Did you try his examples?

Bart Van der Donck wrote:
> Jürgen Exner wrote:
>
>> [...]
>> Assignments never do any interpolation.
>
> Am I using the wrong terminology ?
>
> my $bar = "a";
> my $foo = "bc$bar";
>
> "bc$bar" is the assignment of declaration 'my $foo', right ?
> As I understand it, there is an interpolation of the $bar-variable
> inside the assignment of $foo, so $foo gets value "bca".

Interpolation is the correct term, but it has nothing to do with assignment.
It happens when you define a string, i.e. when using those quotes. And any
text enclosed in double quotes is interpolated, regardless of assignment or
not.

> The problem is that I want a variable to have the exact value as I
> typed it in the code, regardless of which characters I use (assumed,
> within the limitations of the OS and of Perl).

Well, but you are asking Perl _explicitely_ to interpolate that string. If
you don't want interpolation then don't use double quotes. Use single quotes
instead, just like I did in my sample program that you snipped so
conveniently.

jue

Bart Van der Donck wrote:
> Jürgen Exner wrote:
>> Assignments never do any interpolation.
>
> Am I using the wrong terminology ?
>
> my $bar = "a";
> my $foo = "bc$bar";
>
> "bc$bar" is the assignment of declaration 'my $foo', right ?
> As I understand it, there is an interpolation of the $bar-variable
> inside the assignment of $foo, so $foo gets value "bca".

Yes, but the interpolation is done by the double quotes, not by the
assignment. What you want is a quote operator which doesn't do any
interpolation.

>> And suggestion for what? You didn't tell us what you are
>> really trying to do.
>
> One could think of a number of application fields, for example, a
> variable that holds the contents of a .gif file.


This is not possible.

Firstly, a GIF file of any non-trivial length will
almost certainly contain all possible byte values and therefore also the
end-quote character if it is only a single character. So you cannot use
a "begin quote/end quote" quoting mechanism. You would either need
counted strings or an arbitrary multi-byte delimiter (which perl already
has with here-documents.

Secondly, a GIF file will usually also contain the byte which
corresponds to the newline character on the current platform. This is
not portable between platforms, so the GIF file would be destroyed
simple by running the script on a different platform.

Even if it was possible, why would you want to do this? A script with
embedded binary content is extremely fragile: Edit is once with a
less-then-perfect editor and you have made it unusable. Furthermore,
nobody is able to type in syntactically correct GIF files. And if you
want to copy an existing GIF file into a perl script it is very simple
to just add the necessary escapes (perl is very well suited for writing
such conversion scripts .

> Just any case where one needs to be sure the typed characters will
> become the exact value of the variable under any circumstances.

There is no case where you need to be sure of this. You just need to be
sure the typed characters become the characters you want.

hp

--
_ | Peter J. Holzer | Man könnte sich [die Diskussion] auch
|_|_) | Sysadmin WSR/LUGA | sparen, wenn man sie sich einfach sparen
| | | | würde.
__/ | http://www.hjp.at/ | -- Ralph Angenendt in dang 2006-04-15

Denver wrote:

> Bart Van der Donck wrote:
> > my $bar = "a";
> > my $foo = "bc$bar";
> >
> > "bc$bar" is the assignment of declaration 'my $foo', right ?
>
> No. It is a string expression.

Assignment (also 'initialization' or 're-initialization') sets or
re-sets the value of a variable, I think we can agree on that
definition ?

So, I'ld say my terminology still stands.

I wouldn't use a statement "Assignments don't do interpolation" like
Jürgen. Though it's scientifically correct (the assignment doesn't
*do* it, it are the double quotes that do it), it sounds like it's
impossible to use interpolation inside assignments. Therefore I'ld
rather state "Interpolations occur inside assignments if double quotes
are used to perform the assignment".

> > As I understand it, there is an interpolation of the $bar-variable
> > inside the assignment of $foo,
>
> That's incorrect.

I don't see what's wrong with my statement. I just happen to use double
quotes for my assignment here, so the interpolation took place inside
my assignment.

> >> To me it looks like a misguided attempt to solve a perceived
> >> problem.
> >
> > The problem is that I want a variable to have the exact value as I
> > typed it in the code, regardless of which characters I use (assumed,
> > within the limitations of the OS and of Perl).
>
> Do you mean simply no interpolation?

Yes, no interpolation, and also no escape (as I originally wrote).

> > One could think of a number of application fields, for example, a
> > variable that holds the contents of a .gif file.
>
> That's outside the limitations of Perl.

No. Perl variables may hold the contents of a gif-file correctly:

#!/usr/bin/perl
print "Content-Type: image/gif\n\n";
$file = 'plan.gif';
open my $F, '<', $file || die "Cant open $file: $!";
$chars_of_gif.=$_ while(<$F>);
close $F || die "Cant close $file: $!";
print $chars_of_gif; # $chars_of_gif holds gif file here

Running it as CGI shows that the content is correct. So I'ld conclude
it's not a Perl issue, but a OS and/or editor issue.

> You can't put in an arbitrary binary literal in line in your code.
> (I don't really know why you want to.)

Yes, that seems impossible indeed. Maybe with the perfect editor under
the perfect OS ?

> But as Jue showed you, you can have string literals without interpolation.
> Did you try his examples?

print '$foo\\n';

does not print the literal text, but prints:

$foo\n

--
Bart

Jürgen Exner wrote:
> Bart Van der Donck wrote:
>> The problem is that I want a variable to have the exact value as I
>> typed it in the code, regardless of which characters I use (assumed,
>> within the limitations of the OS and of Perl).
>
> Well, but you are asking Perl _explicitely_ to interpolate that
> string. If you don't want interpolation then don't use double quotes.
> Use single quotes instead,

Well, single quotes (unlike single-quoted here-documents) "interpolate"
(I personally wouldn't use that term for escape-sequences, but perldoc
perlop does) \\ to \ and \<end-of-quote> to <end-of-quote>. I'm not sure
why they do - it seems like a remnant of before the day q() was
invented, because it shouldn't ever be necessary to escape the
<end-of-quote> character these days, and then escaping the backslash
isn't necessary, either.

hp

--
_ | Peter J. Holzer | Löschung von at.usenet.schmankerl?
|_|_) | Sysadmin WSR/LUGA |
| | | | Diskussion derzeit in at.usenet.gruppen
__/ | http://www.hjp.at/ |

Bart Van der Donck wrote:
> Denver wrote:
>> Bart Van der Donck wrote:
>> > my $bar = "a";
>> > my $foo = "bc$bar";
>> >
>> > "bc$bar" is the assignment of declaration 'my $foo', right ?
>> No. It is a string expression.
>
> Assignment (also 'initialization' or 're-initialization') sets or
> re-sets the value of a variable, I think we can agree on that
> definition ?
Yes. But you are confusing this with how it obtains the value to be assigned.


> So, I'll say my terminology still stands.
I say it doesn't.


> I wouldn't use a statement "Assignments don't do interpolation" like
> Jürgen. Though it's scientifically correct
It is correct.


> (the assignment doesn't *do* it, the double quotes do it),
Correct in that context.


> it sounds like it's impossible to use interpolation inside assignments.
I have no problem with that.


> rather state "Interpolations occur inside assignments if double quotes
> are used to perform the assignment".
That has a bunch of bogus baggage.

Explain:
print "bc$bar";

Are you going to say: "Interpolations occur inside print statements if double quotes are used to perform the printing"?
Obviously that is nonsense and it only gets worse.


>> > As I understand it, there is an interpolation of the $bar-variable
>> > inside the assignment of $foo,
>> That's incorrect.
> I don't see what's wrong with my statement.
Because interpolation happens completely independent of, outside of, and before any assignment.

> the interpolation took place inside the assignment.
That is false.


>> >> To me it looks like a misguided attempt to solve a perceived
>> >> problem.
>> >
>> > The problem is that I want a variable to have the exact value as I
>> > typed it in the code, regardless of which characters I use (assumed,
>> > within the limitations of the OS and of Perl).
>>
>> Do you mean simply no interpolation?
> Yes, no interpolation, and also no escape (as I originally wrote).
Then use quotes that do not do interpolation. Is this too difficult?


>> > One could think of a number of application fields, for example, a
>> > variable that holds the contents of a .gif file.
>> That's outside the limitations of Perl.
> No. Perl variables may hold the contents of a gif-file correctly:
They certainly may.

> So I'll conclude it's not a Perl issue
You are still wrong.


>> You can't put in an arbitrary binary literal in line in your code.
>> (I don't really know why you want to.)
> Yes, that seems impossible indeed. Maybe with the perfect editor under
> the perfect OS ?

What syntax do you propose?

Bart Van der Donck wrote:
> Assignment (also 'initialization' or 're-initialization') sets or
> re-sets the value of a variable, I think we can agree on that
> definition ?

So far, so good.

> So, I'ld say my terminology still stands.
>
> I wouldn't use a statement "Assignments don't do interpolation" like
> Jürgen. Though it's scientifically correct (the assignment doesn't
> *do* it, it are the double quotes that do it), it sounds like it's
> impossible to use interpolation inside assignments.Therefore I'ld
> rather state "Interpolations occur inside assignments if double quotes
> are used to perform the assignment".

Sorry, you are missing the point. Quotes and assignment are totally
independant concepts. The one has nothing to do with the other.
There are quotes that are not part of an assignment: if ($foo eq
'$MyFavouriteValue') {..}
And there are assignment that don't use quotes: $a = $foo X 3;
And then there are cases where they happen to be used together: $a = "My
Text";

Your statement is rather like saying "addition occurs inside of an
assignment if the expression on the right hand side contains a plus sign".
Yeah, sure, that's correct. But it's totally missing the point by explaining
one special case instead of the generalized concept.

jue