[...]I suppose another approach is simply to declare that dot is always a metacharacter in double quotes, and you have to use \. for a literal dot, just as in regexen. That approach would let us interpolate things like .foo without a variable on the left. That could cause a great deal of cultural confusion in the short term, however.
Ouch. I'm thinking we allow $foo.bar in both strings and regexen, but not .bar in either case. Gotta use $_.bar inside strings and regexen. (Or $(.bar) would work too.) Possibly we even complain about /.bar/ and force them to write /. bar/.
Please, think of C<say "This is a sentence. This is another sentence.";>. Dots with whitespace or end-of-string after them should just be literal dots in qq strings. Dots should always be literals in q() strings, of course. And dots are /already/ metacharacters in regex^Wrules; forcing a space after the dot isn't giving the power of formatting to the user; it's forcing formatting upon them that they don't want. (I don't remember if there's an adverb to treat spaces as literals, but if not, there should be.)
I think method calls in strings should be "Foo's bar is $($foo.bar).", plain and simple. Dot is too useful here already. @{[...]} needed to be replaced with something easier to type, and with clearer (and cleaner) semantics. We did that; $(...) is far better. Not requiring a set off for method calls is Huffman coding the wrong direction, unless you can find one that won't disturb useful things that you'd want in double-quotes -- which includes patterns common in any natural language, which includes even the literal versions of << / >> (which I can't type easily at the moment).
-=- James Mastros
