Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!yale!think!zaphod.mps.ohio-state.edu!uwm.edu!lll-winken!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: length operator
Keywords: quibble
Message-ID: <7086@jpl-devvax.JPL.NASA.GOV>
Date: 16 Feb 90 03:48:32 GMT
References: <13103@cgl.ucsf.EDU> <1990Feb15.230159.8255@iwarp.intel.com>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Distribution: comp
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 87

In article <1990Feb15.230159.8255@iwarp.intel.com> merlyn@iwarp.intel.com (Randal Schwartz) writes:
: In article <13103@cgl.ucsf.EDU>, pett@cgl (Eric Pettersen) writes:
: | 
: | 	IMHO, the "length" operator should not allow the "length EXPR" syntax.
: | I often want to handle "length-2" which, because the above syntax is legal,
: | forces me to write "length($_) - 2" instead.  Not to mention causing me some
: | lost time while trying to figure out why "length-2" doesn't work.  This has
: | probably caught other people as well.  Does "length EXPR" have any supporters?
: 
: $_ = "a long string";
: $len = (length)-2;
: print "the length is $len\n";
: $len = length()-2;
: print "the length is still $len\n";
: 
: prints:
: 
: the length is 11
: the length is still 11
: 
: Okay, so it is still a bit icky.  Being able to type "length > 128" (a
: good thing) means having that silly optional EXPR stuff (a bad thing).
: Maybe there's an alternate, but it won't make it into patch 9. :-)

I doubt I'll ever "fix" it.  In perl 2.0, we had the problem that you couldn't
tell which single-argument operators were allowed to be unary (that is,
without the parens), and which ones weren't.  The list operators were also
a mess.

In 3.0, I decided to regularize the unary and list operators.  The rules
are very consistent now.  Unfortunately, this makes a couple of counter-
intuitive spots in the language, but I think that's the price that has
to be paid.

Of the two spots, you've discovered one.  A unary operator, in order to
have an argument, must expect the next thing to be a term.  You can
(currently) get away with "length > 128" because no term starts with ">"--
it must be a binary operator.  But there are many characters that
can begin both terms and operators.  F'rinstance:

		Operator		Term
	+	addition		unary plus
	-	subtraction		unary minus
	*	multiplication		*name
	/	division		/pattern/
	<	less than, left shift	<filehandle>, <<EOF
	.	concatenation		.3333
	?	?:			?pattern?
	%	modulo			%assoc
	&	&, &&			&subroutine

You don't realize that the language has all this ambiguity resting on 
whether a term or operator is expected, because that's just not how
our minds work.  Unfortunately, the parser can't read minds.

If I outlawed unary operators, all the following would become illegal:

	chdir "/usr/local/bin";
	chroot "/usr/spool/ftp";
	eval "\@$device = something";
	sleep 20;
	exit 1;
	reset 'a-z';
	rmdir 'try';
	umask 0777;

I don't think you want those outlawed.

The other sticky spot is when you say

	print (1<<20),"\n";

which is the same as

	(print 1<<20), "\n";

There are a few basic rules.  When in doubt, put parens around a function's
arguments, and you'll never go wrong.  (Well, almost never.)  And, don't
take defaults unless you know what you're doing and have a good reason
for being lazy.  If the item following a unary operator could be construed
as a term, throw in a (), which forces the next token to be constued as
an operator.

That's just about all you have to worry about, except for the weirdities
that perl shares with C (like precedence of & and |).

Larry