program in a language where the value of an expression changes depending whether there's whitespace between tokens or not.

Like Perl 5?

print 3 . 5;
print 3.5;

print "$foo{bar}";
print "$foo {bar}";
[download]

And yes, I know certain people hate it. They can write their own grammar.

print 3 . 5;
print 3.5;
[download]

I fail to see your point here. In the first line, there are 5 tokens, 'print', '3', '.', '5', and ';'. In the second line there are 3 tokens, 'print', '3.5', and ';'.

print "$foo{bar}";
print "$foo {bar}";
[download]

Indeed, and something that doesn't make me very happy. Luckely this is a problem that is usually found by the compiler, assuming you have 'strict' turned on, and don't have a scalar with the same name as the hash.

And yes, I know certain people hate it. They can write their own grammar.

Oh, I read that. Do you think that if people start writing their own grammars (of which I haven't seen any indication that it will be anything but hard to get it right) that that will produce maintainable code?

Abigail

Do you think that if people start writing their own grammars (of which I haven't seen any indication that it will be anything but hard to get it right) that that will produce maintainable code?

Yes, I do. (And probably will have a grammar or bunch of macros of my own)

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

The closest example to this that I've run into is extremely close. When Perl changed the interpretation of "print (" to be the same as "print(", I found that the problems clearly increased, and stayed up even long after the change. So I enthusiastically support Perl6's idea to not allow whitespace in a few key places where whitespace has no good reason to be.

Putting whitespace between a hash and the '{' makes as much sense to me as wanting to write "10 . 45 e - 12" because it is "easier to read" (no, actually wanting spaces in some numbers makes more sense to me).

Not all whitespace improves readability. "$foo {bar}" looks like a scalar followed by something and causes me to fault and backtrack in my parsing of the code when I can't figure out why the code even compiles. Why have you crouded $ and foo so close together? That must be hard for you read. q-:

I realize that the tokenizer considers the tokens to be '$', 'foo', then '{' for that case but considers '10.45e-12' to be single token. But my "tokenizer" sees '$foo{' as a single conceptual token and breaks the number into '10.45' and 'e-12'.

We've also put in an escape hatch for when you really need whitespace there. A subscript or argument list can be detached if you put a dot in front of it:

    print .($bar)
    %foo  .{'bar'}
    @abc  .[123]
[download]

In theory, we could require no whitespace before ++ too, but we don't actually need to unless someone defines a binary operator ++, whereupon the correct response is to shoot them.

The closest example to this that I've run into is extremely close. When Perl changed the interpretation of "print (" to be the same as "print(", I found that the problems clearly increased, and stayed up even long after the change. So I enthusiastically support Perl6's idea to not allow whitespace in a few key places where whitespace has no good reason to be.

When was that, in the perl4 era? As far as I can remember, print has behaved the same as any other function, allowing you to have whitespace between the function name and the opening parenthesis - except that 'print' will whine if you actually use parenthesis (if you have warnings turned on, and haven't disabled the warning).

$ cat tye
print (3 + 4) * 5; print "\n";
print(3 + 4) * 5;  print "\n";
$ /opt/perl/5.000/bin/perl tye
7
7
$
[download]

If it was different in perl4, then I'm sure glad that in perl5 we don't have exceptions in the parsing of functions/arguments depending on the function name.

Note that in perl1 different results are printed - but at least they are consistent:

$ /opt/perl/1.0.0/bin/perl tye
35
35
$
[download]

Putting whitespace between a hash and the '{' makes as much sense to me as wanting to write "10 . 45 e - 12" because it is "easier to read" (no, actually wanting spaces in some numbers makes more sense to me)

Well, you can't put spaces inside numbers (for more or less obvious reasons), but Perl does have an alternative: it allows you to put underscores in numbers - for exactly that: better readability. Putting a space between the name of an aggragate and its index makes as much sense to me as to separate an adjective from a noun in an English sentence. $hash {index} is an operation (a mapping in this case) with two operands: a hash, and a string. A function call is also a mapping, but with a variable number of arguments. How do you call a function with say 5 arguments (say, a push of four elements on an array)? Do you call it like:

    push@array,"second","third","fourth","fifth";
[download]

Or do you put in some whitespace? And if one puts in whitespace, then why not put whitespace between the name of the function and the first argument?

Oh well, at least this will cause the Python people to have a field day. They always got laughed at (often by Perl folks) for their "whitespace rules". And now we got perl6. At least in Python, the whitespace rules are sane.

Abigail

When I heard of your whitespace issues with Perl6 in earlier Apocalypses, I thought you were over-reacting. But after reading Apoc. 12, I'm ready to jump on board (though perhaps not with the same vigor).

Though I've never seen a language that is completely free of whitespace restrictions, it's usually because the designers could only go so far in getting rid of it. I don't like seeing it put intentionally into a language.

(Perhaps my only exception is OCaml, where function parameters are seperated by whitespace. You've got to seperate them with something, and I don't think making the choice between seperating with 0x20 instead of 0x2C is a big deal. I haven't used it enough, though, to see if it makes a difference in real code.)

Though I've never seen a language that is completely free of whitespace restrictions

I have. But such languages invariably have much simpler syntax than Perl. In most cases they're oddball languages created for hack value that advertise Turing-equivalence as an important feature and have never been used (or intended) for anything serious.

As far as real languages, Perl5 has fewer and more reasonable whitespace restrictions than average I think. I do wish we had whitespace-folding multiline strings like in Inform (but not at the expense of regular strings). I believe Perl6 will allow such a syntax to be added to the grammar without having much impact on anything else (provided the syntax for it is carefully chosen to not conflict), which will be nifty. Some of the languages in the lisp family are pretty reasonable about their use of whitespace too. You do have to have whitespace between items in a list, but it makes no difference how much whitespace or what kind, and the restriction is unlikely to bother anyone since the whitespace is not redundant: it's the only syntactic element between items in a list. (Usually the syntactic feature that bothers people about these languages is the pervasive use of parentheses, especially if said people aren't accustomed to using an editor with paren-matching, auto-indentation, and sexp-based cursor navigation. Perl goes the other way and allows you to use a lot fewer parentheses than many other popular languages, and I think this is going to stay mostly the same in Perl6.)

---

;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print

I'll be the VP of Bring-Back-Ref-Counting bitching. But I'll continue to do the vast majority of my bitching the Lazy Way. If I do nothing for long enough, I'm certain to get ref-counting back into Perl (you had to be there).

- tye        

Hear hear! I'll go one further and say that perl5's stack should be refcounted. Death to Mortals! No more Temps! Just say NO to Reification!