Larry Wall wrote:
On Wed, Mar 26, 2008 at 12:56:08PM -0600, Thom Boyer wrote:
Larry Wall wrote:
... In the
limit, suppose some defines a postfix "say" looser than comma:
(1,2,3)say
1,2,3say
1,2,3.say
I must be missing something. Wouldn't it be easier to write
1,2,3 say
since say was defined to bind looser than comma? Then you wouldn't need a
nospace unspace.
The part of Perl 6 that bothers me most is the whitespace dwimmery that
required unspace in the first place. I'd hate to see more of it.
Not that I have a better solution than the proposed whitespace dwimmery,
mind you.
How would you keep infix operators in a separate namespace from postfix
then? As soon as someone defines infix:<++> you're hosed, or we have
to throw out all term/infix distinctions that Perl has always had. How
would you parse
$x ++ /foo/;
It also completely destroys the current absolute distinction between
say(1 + 2), 3
say (1 + 2), 3
Larry
Yup. You gotta have some way to resolve those problems, and the
whitespace distinction does the job. And, as I said, I don't have a
better solution.
But that doesn't obviate my unease with whitespace being so very
significant to the meaning of a program. Perhaps it comes from exposure
to Fortran IV at an impressionable age -- a language in which nothing
changes if you remove ALL whitespace (outside of Hollerith constants,
that is). It might be fair to liken that exposure to the effects of
Thalidomide: perhaps my brain's been deformed.
But it's only an unease, and I recognize that it's a bias I acquired by
programming in so many different languages in which whitespace is
insignificant. I further recognize that Perl offers a lot of way-cool
stuff that wouldn't be possible with out whitespace dwimmery.
I *love* list operators. Being able to write, in Perl 5,
foreach_vertex $polygon, sub {
# executed once for each vertex, with the vertex in $a
print "point #", $n++, ": $a\n";
};
instead of
foreach_vertex($polygon, sub {
# executed once for each vertex, with the vertex in $a
print "point #", $n++, ": $a\n";
});
makes a world of difference to readability. And I'd be *tempted* to
resolve the the ambiguity in
say (1 + 2), 3
by treating that as
say(1+2), 3
and requiring (function-call, not list-operator) syntax like
say((1+2), 3)
if you want the other. But that would have a horrible effect. If I
started with
say $x*2, 3
and then realized I needed to add one to $x before doubling, I'd be
surprised by the resulting treatment of
say ($x+1)*2, 3
So you made the right call there, in my opinion. The whitespace makes
clear the programmer's intent, once you're used to list operators.
As for:
> $x ++ /foo/;
well, for that case, I can't even think of a BAD suggestion to make, so
whitespace dwimmery is again the best solution I know.
And yet that whitespace-is-insignificant meme keeps tickling my brain.
And what really cranked it up to poison-ivy level was the unspace. I
can't even explain why. I don't even *understand* why, myself, so I can
hardly speak on the subject in a cogent manner.
I suspect it's an emotional, irrational, reaction. I probably just need
to just scratch the inside of my skull with a wire brush until the itch
is gone. And quit bothering the list with my idiosyncrasy. After all,
it's an entirely artificial idea in the first place -- because,
to humans,
whitespace
really
DOES
matter;
it's
only
those
stupid
compilers
that feel
otherwise.
-----
But the main point I was trying to make is just that I didn't see the
necessity of positing
1,2,3\say
when (if I understand correctly) you could write that as simply as
1,2,3 say
And if someone really wants to apply a C<t> postfix operator in a string
interpolation, then let them say
say "blah {$x t} blah"
That seems better to me than saying that there's no tab character in
say "blah $x\t blah"
Backslashes in double-quotish contexts are already complicated enough!
=thom
