Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!jarthur!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: suggestion for dbmopen
Message-ID: <11231@jpl-devvax.JPL.NASA.GOV>
Date: 30 Jan 91 17:15:38 GMT
References: <281@sran84.sra.co.jp> <COMPOSER.91Jan29102909@chem.bu.edu> <1991Jan29.163953.15953@convex.com> <283@sran84.sra.co.jp>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Distribution: comp
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 26

In article <283@sran84.sra.co.jp> utashiro@sran84.sra.co.jp (Kazumasa Utashiro) writes:
: I don't want to complain about this at all.  It isn't too
: bad and documented well.  Just an idea.

It's not a bad idea.  I just don't think it happens often enough to be
worth the effort of dealing with all the shift-reduce ambiguities it
would introduce.  The "do" operator is already too heavily overloaded,
and it would be easy to lose the trailing parens.  (This is a problem
in C and all C-derived languages--in fact, in any language with a mixture
of prefix and postfix operators.) Even if the compiler can keep track
of the trailing parens, the poor slob trying to read the code may easily
overlook them.  I think that forcing the programmer to name temporaries is
not always an evil.

This brings up the whole issue of pipelines vs. temp files, but you'll note
that a pipeline can be read left to right, while a typical C expression
has to be read from both ends at once, or perhaps from the inside out.
To a smart compiler, of course, it makes no difference which way you write
it, since the temporary can be looked at as a definition rather than
an actual storage location.  I'm not claiming Perl is that smart yet.

Perl doesn't allow nested quote interpretation either, which also forces
you to make temporaries at times.  I consider this to be an anti-obfuscatory
feature.

Larry