On Wed, Nov 23, 2005 at 02:23:51PM +0100, Ruud H.G. van Tol wrote:
: Larry Wall:
:
: for ^5 { say } # 0, 1, 2, 3, 4
:
: The 'for' can go if a list (and also an array) would imply looping, when
: it is positioned next to a block:
:
: a. say (0..4);
: b. { say; say } (0..4);
: c. (0..4) { say; say }
: d. @{0..4} { say; say }
: (etc.)
:
: b. now produces 2 lines with 01234 (in pugs).
Which is wrong by the current spec, by the way. It should be a syntax
error to have two terms in a row. Bare parens can't be function args
unless they're abutted or use ..
: With implied looping that would be 10 lines, starting with two 0-lines.
I don't like that much deep magic without a keyword to clue the reader,
and we have plenty of keywords to work it already:
for ^5 { say }
^5.each { say }
(0..4).each == say
say for ^5;
I can see the mathematical appeal of coming up with a language in
which there is a meaning for every possible combination of tokens.
But there's an important linguistic principle here that I think has
never been adequately researched, and is probably worth a doctorate
to whoever does it. But it's a subtle principle, so it's rarely
mentioned. That principle is that there has to be some kind of
self-clocking aspect to a syntax, or you never realize if you've
gotten out of sync. In other words, there have to be some sequences
in the syntax that are syntax errors, or you'll never get any syntax
errors. That sounds like a tautalogy, but I don't mean it that way.
The self-clocking, phase-locked-loop aspect of Perl is driven by the
fact that we almost never allow two terms in a row, and also by the
fact that it's pretty easy to distinguish terms from operators most
of the time. This is what allows Perl to be a language that does,
in fact, overload leading characters between terms and operators
rather heavily. But if we allowed you to say $foo %bar and gave
it some meaning, you wouldn't be able to tell whether that % should
be a sigil or a modules operator.
And we also have to be careful about terms like {...} and (...) and
[...]. We've already made the exception that you can have {...} where
an operator is expected--that's exactly how the grammar recognizes
the difference between
for foo 1,2,3 {...}
and
for foo 1,2,3,{...},{...},{...} {...}
But it's easy enough to get tangled up with that exception, and if we
start making any sequence of bare brackets mean something, we'll not
get a syntax error but an unexpected successful parse, which can be
far more devastating than a syntax error.
However, in order to milk our bracketing characters for all they're
worth, as well as all the other operators, we finessed it in Perl 6
depending on the whitespace (or .) so that we can tell which
operators are intended as postfix operators and which ones are
misplaced terms. And that's why
{say} (1)
has to be a syntax error, while
{say}(1)
{say}.(1)
are just function calls. We really have to make that rule, or people
will be very confused a very large amount of the time. And the worst
part of it is that they'll think it's because they're stupid, not
because the language is poorly designed. It's a counterintuitive fact
that languages that are too efficiently coded induce inefficiencies in
communication. We're already dancing on the brink of too efficient,
and it would be easy to fall over the edge. Some would say we already
have...
Larry
