rbj@uunet.UU.NET (Root Boy Jim) (02/08/91)
Are patterns a semi data type in their own right? Are they replacable with strings? The manual/book never addresses this explicitly. My experiments lead me to belive that whenever a "pattern" is expected, slashes are "promoted" to double quotes, as if "qq" had been stuck in front. -- Root Boy Jim Cottrell <rbj@uunet.uu.net> I got a head full of ideas They're driving me insane
tchrist@convex.COM (Tom Christiansen) (02/08/91)
From the keyboard of rbj@uunet.UU.NET (Root Boy Jim):
:Are patterns a semi data type in their own right?
:Are they replacable with strings?
:The manual/book never addresses this explicitly.
:
:My experiments lead me to belive that
:whenever a "pattern" is expected, slashes
:are "promoted" to double quotes, as if "qq"
:had been stuck in front.
A semi-data type? I'm not sure what a real data type is. I think by the
most stringent criteria (you can have anonymous temporaries), only atoms,
oops I mean scalars :-), and lists are real data types, and everything
else is just some magic operation you perform on them, like regexp
matching, hashed array lookups, code evals, and indirect function calls
and i/o. But I don't really tell people that (often). Usually I consider
anything that you can pass around and has its own name space is a real
data type.
I believe your observations to be correct. I think Larry once explained that
if ($a =~ $b)
is legal, and counts as
if ($a =~ /$b/)
but it may be somehow less efficient. Certainly it's fair to use
variables in pattern patching operations. Various tricks (like //,
/$foo//o, eval, ...) can be used to speed up the operation.
Note that if you use alternate delims on the match, like m#bar#, it still
gets qq// interpolated, unless you should use m'bar', in which case you
get q// action. I'm not sure I've ever seen this written down in the man
page or the book. I don't think you can use m`bar` for qx// action, but
neither can I think of why you'd ever want it to.
--tom
--
"All things are possible, but not all expedient." (in life, UNIX, and perl)merlyn@iwarp.intel.com (Randal L. Schwartz) (02/08/91)
In article <1991Feb07.210023.8308@convex.com>, tchrist@convex (Tom Christiansen) writes: | I don't think you can use m`bar` for qx// action, but | neither can I think of why you'd ever want it to. 1) It works. (Well, the s`foo`bar` form works.) 2) For a JAPH, of course! s`^`echo Just another Perl hacker, >&2`; -- /=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\ | on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn | \=Cute Quote: "Intel: putting the 'backward' in 'backward compatible'..."====/
rbj@uunet.UU.NET (Root Boy Jim) (02/08/91)
In article <1991Feb07.210023.8308@convex.com> tchrist@convex.COM (Tom Christiansen) writes: >From the keyboard of rbj@uunet.UU.NET (Root Boy Jim): >:My experiments lead me to belive that >:whenever a "pattern" is expected, slashes >:are "promoted" to double quotes, as if "qq" >:had been stuck in front. > >I believe your observations to be correct... > >Note that if you use alternate delims on the match, like m#bar#, it still >gets qq// interpolated, unless you should use m'bar', in which case you >get q// action. I don't think you can use m`bar` for qx// action, but As merandalyn mentioned, quote type matters on s commands. However, m'$var' == m"$var" == m`$var`. And tr is brain dead. I have to use eval to get vars into either side. 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. And by "data types", I meant "string" vs "numeric". I know.... >neither can I think of why you'd ever want it to. Famous last words. >--tom -- Root Boy Jim Cottrell <rbj@uunet.uu.net> I got a head full of ideas They're driving me insane
tchrist@convex.COM (Tom Christiansen) (02/08/91)
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.
I think that this illustrates that single quotes DO matter:
$_ = 'contains $foo in it';
$foo = 'bar';
print "match in singles: ", m'\$foo', "\n";
print "match in doubles: ", m"$foo", "\n";
print "match in backs: ", m`$foo`, "\n";
$foo = 'tain';
print "foo is $foo\n";
print "match in singles: ", m'\$foo', "\n";
print "match in doubles: ", m"$foo", "\n";
print "match in backs: ", m`$foo`, "\n";
: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 $_. This:
join(/foo/, 'a', 'bird', 'in', 'the', 'hand');
yields
'a1bird1in1the1hand'
if you leave $_ at what it was above, and
'abirdinthehand'
in most other cases.
: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.
--tom
--
"All things are possible, but not all expedient." (in life, UNIX, and perl)rbj@uunet.UU.NET (Root Boy Jim) (02/08/91)
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