Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!rbj
From: rbj@uunet.UU.NET (Root Boy Jim)
Newsgroups: comp.lang.perl
Subject: Re: Patterns vs Strings
Message-ID: <121718@uunet.UU.NET>
Date: 8 Feb 91 09:00:07 GMT
References: <1991Feb07.210023.8308@convex.com> <121661@uunet.UU.NET> <1991Feb08.034916.29904@convex.com>
Organization: UUNET Communications Services, Falls Church, VA
Lines: 78

In article <1991Feb08.034916.29904@convex.com> tchrist@convex.COM (Tom Christiansen) writes:
>From the keyboard of rbj@uunet.UU.NET (Root Boy Jim):
>:However, m'$var' == m"$var" == m`$var`. And tr is brain dead.
>:I have to use eval to get vars into either side.
>
>Well, I wouldn't call tr braindead just because it doens't
>do something it's not documented to do.  

Something is braindead if it doesn't do what it OUGHT to do.
Of course, that OUGHT is open to debate :-)
TR could use magic on either side.

>I think that this illustrates that single quotes DO matter:

And I think you will eat your words on this one.

>    $_ = 'contains $foo in it';
>
>    $foo = 'bar';
>    print "match in singles: ", m'\$foo', "\n";

I claim that the single quotes act like double quotes,
and therefore you are asking if $_ contains '$foo'; result 1
Now if you had switched the backslash from one example to
the other and gotten 1 in both cases, then I'd say you were right.

>    print "match in doubles: ", m"$foo", "\n";

We all agree that we are asking if $_ contains bar; result is "".

>    print "match in   backs: ", m`$foo`, "\n";

This is precisely the same as the other two. result is "".
Try matching against `kill -9 $$` to prove my point.

>    $foo = 'tain';
>    print "foo is $foo\n";
>    print "match in singles: ", m'\$foo', "\n";

Here, you are matching the $foo string literally.
Try setting $_ to 'contains' and you will get "".

>    print "match in doubles: ", m"$foo", "\n";
>    print "match in   backs: ", m`$foo`, "\n";

Both of these match $_ against tain. result is 1.

>:However, once again, I have not made myself clear. I am talking
>:about the first argument to split and join. Normally, you can't
>:just go passing strings to functions/operators by /quoting/ with slashes.

>I wouldn't say "normally" -- I would say "never"!  Putting /slashes/
>around a string it a run-time pattern match against $_.

I goofed! Looks like only split is special. Like the space after
the optional FILEHANDLE on printf? and the SUBROUTINE on sort,
the first argument to split is an oddball. And it seems that
each place a pattern can appear, it's treated differently.

>:And by "data types", I meant "string" vs "numeric". I know....
>
>But those are just the same scalar data type, which is a wee bit 
>polymorphic.  But this part might just be a matter of semantics.

Yeah, just like the difference between "functions" and "operators".  In
LISP, numbers (integer, float, bignums, rationals), strings, and lists
are all considered data types. In APL, numbers and characters are the
data types, and may have any shape. In perl, shapes are the data types,
and format of scalars is relatively unimportant.

>--tom
>--
> "All things are possible, but not all expedient."  (in life, UNIX, and perl)
-- 

	Root Boy Jim Cottrell <rbj@uunet.uu.net>
	I got a head full of ideas
	They're driving me insane