> 16:50 < audreyt> Juerd: write to p6l and explain the ".." conflict,
The current long dot consists of a dot, then whitespace, and then another dot. The whitespace is mandatory, which makes the construct at least three characters long. Tripling the length of an operator, just to make it alignable, is quite a lot. Illustration: $xyzzy.foo(); $fooz. .foo(); # doesn't line up, so we have to change the # *previous* line! $foo. .foo(); # this lines up again. So we use: $xyzzy. .foo(); $fooz. .foo(); $foo. .foo(); which is ugly and feels bad. It feels bad, because we're adding much more whitespace (two character positions in total) than we had to bridge. And it's a lot of work (many, many keystrokes!) to go back and change something. However, the whitespace in between cannot simply be made optional, as then it would clash with the range operator. As ranges are even more important than a sane "long dot" solution, the long dot had to change. Larry indicated that changing the long dot would have to involve changing the first character. The only feasible solution in the "tiny glyphs" section was the backtick. I refrain from explaining why that will widely be considered a bad idea. Audrey cleverly suggested that changing the second character would also work, and that has many more glyphs available. So she came up with > and propose ".:" as a solution, That's right, dot-colon. There are more glyphs available, but none of them is nice like this. The basis is in regexes, where a colon means you commit to have parsed the left side of the colon. That's how the colon already reads in the indirect object notation, and the colon in $foo.map:{...} can already be read. So the actual solution is to make the method call operator not ".", but ".:". Of course, a lone "." still works and is the recommended style for all simple method calls that don't have to be lined up. You can also explain it as "." still being the base operator, where ".:" is a special form. Whatever you like best :) > and ". :" as an extension, Of course, it wouldn't be a solution to the long dot problem if it didn't allow an arbitrary amount of whitespace in between. So, obviously, it does allow lots of whitespace in between. And, of course, comments. If you really hate your future maintainer, you could even put some POD in between. $xyzzy.foo(); $fooz.:foo(); $foo. :foo(); Or, if you prefer: $xyzzy.:foo(); $fooz. :foo(); $foo. :foo(); Or, if you actually LIKE the extra whitespace that the current long dot mandates: $xyzzy. :foo(); $fooz. :foo(); $foo. :foo(); > and ". +" as an generalization, Of course, this works nicely with the operators it was inspired by, that were also inspired by regex postfix operators: ".*", ".+" and ".?". They can also contain whitespace in our proposal. The dot-colon fixes another problem too. You couldn't line them up anymore: $foo.?bar(); $foo.baz(); # makes the ? look like part of the method name So, now you can: $foo.?bar(); $foo.:baz(); And an illustration with whitespace in between: $xyzzy.:foo(); $fooz. ?foo(); $fo. *foo(); > and coexistence/removal of ". ." as a consideration If we have dot-colon, we could keep the old long dot too. That would work well with my preference for "..." as the first part of the old long dot, as three dots stand out much better at the end of a line: $foo... .bar(); Though that isn't really dependent on the old long dot. It can live separately. In fact, postfix "..." could be a generic "eat whitespace and pretend it wasn't there" operator: $foo... .bar()... .baz(); $foo... .:bar(); # with normal old long dot, would be :bar(), looking like # a pair, not a method call. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html