On Tue, Nov 30, 2004 at 09:09:39AM +0300, Alexey Trofimenko wrote:
: When I look at this
: $var<key1><key2>[3]<key3>
:
: then I think that it's a *very* cute, nice, and clean syntax... I really
: like it!
: (and I would sacrifice something for that to happen, if I would be Larry
: :) )
: but there's a problem for people and parser too. < is a comparison
: *operator* and hash subscript is *operator* too, and there's no way to
: distinguish them at all. "Term rule" won't help here.
I rather like it too. I'm glad someone else is thinking along the
same lines. The basic problem with �...� is that most of its uses
were turning out to be more useful that the corresponding <...>.
In fact, I was thinking about all this on the way home from Seattle
yesterday (a 15-hour drive), and I think I'm ready to propose a Great
Angle Bracket Renaming.
Here's the proposal.
First the bad news:
* We accept that the C<< < >> operator requires whitespace
around it, and be prepared to be burned in effigy occasionally.
* We steal angles away from iterators.
Now the ugly news:
* Hyper operators stay the same, �op�.
Now with those out of the way, the good news:
* All other uses of �...� and <...> swap, pretty much.
Now, that has certain interesting outcomes.
* We get <...> as the qw// shorthand where a term is expected.
* Most uses of qw// involve strings and lists, so there's little
visual interference with numeric comparison operators.
* We get the cute, clean and rather more typeable
$var<key1><key2>[3]<key3>
* People can probably get used to reading things like:
$var<key1><key2>[3]<key3> < $var<key1><key2>[4]<key3>
* Though they will certainly carp.
* The ordinary angles do a better job of turning the
literal keys into visual pills than �...� do.
* Since we already stole angles from iterators, �$fh� is not
how you make iterators iterate. Instead we use $fh.fetch (or
whatever) in scalar context, and $fh.fetch or @$fh or $fh[]
or *$fh in list context.
* That frees up �...� for Something Else.
* That something else is the requested variant of qw// that allows
interpolation and quoting of arguments in a shell-like manner.
* That means that, roughly, we have this proportion:
'...' : "..." :: <...> : �...�
* Therefore, just as you can use "..." in place of '...' where you
you think it's more readable, you may still use �...� in place
of <...> where that helps readability.
$var�key1��key2�[3]�key3� < $var�key1��key2�[4]�key3�
* Both the �...� and <...> forms work as slices when used as hash
subscripts.
* The Texas quotes <<...>> are only needed when you *have* to interpolate.
* The :w splitting happens after interpolation. So
� foo $bar @baz �
can end up with lots of words, while
� foo "$bar" "@baz" �
is guaranteed to end up with three "words".
* Multimethed references could be distinghuised either way:
&bark�Tree�
&bark<Dog>
* Match vars become $<foo> instead of $�foo�.
* A rule like <ident> now captures, while �ws� or <<ws>> doesn't.
I think I really like that last outcome. Capturing should be the default.
And the low profile of �ws� makes it look like an "oh by the way".
Anyway, feel free to shoot this full of holes.
Larry
