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