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.
Well... this is interesting. I'm wondering, should I recycle my copy of Perl 6 and Parrot Essentials, or keep it as an historical document for future generations to look at and marvel over?
Just kidding, I'm surprising myself by liking this. Let's see if I've understood it.
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.
Personally, I always use whitespace around such operators, so it's no hassle for me for it to be required. Might encourage some more readable code (definition of 'readable' unfortunately still undecided across the programming community).
* We steal angles away from iterators.
Will they miss them? In a way it's nice to have syntax-level support for iteration, but it's no massive hardship to do without.
Now the ugly news:
* Hyper operators stay the same, »op«.
That's not ugly.
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.
So
my @list = <foo bar baz>;
is the equivalent of
my @list = ('foo', 'bar', 'baz');?
* Most uses of qw// involve strings and lists, so there's little
visual interference with numeric comparison operators.
Very true.
* People can probably get used to reading things like:
$var<key1><key2>[3]<key3> < $var<key1><key2>[4]<key3>
* Though they will certainly carp.
They always 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's doable. I take it that if I do
for (@$fh) {
...
}then $fh iterates lazily rather than exploding into an enormous list to be processed and chewing up all the RAM.
* 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.
Mmmm so I can write
my $foo = 'foo'; my $bar = 'bar'; my $baz = 'baz'; my @list = «$foo $bar $baz»;
and get the same @list I got earlier? Mighty cool.
* That means that, roughly, we have this proportion:
'...' : "..." :: <...> : «...»
Elegance, always good.
* 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»
Fabulouser and fabulouser.
* Both the «...» and <...> forms work as slices when used as hash
subscripts.
I don't think I've ever used a hash slice in my life. Is there something wrong with me?
* The Texas quotes <<...>> are only needed when you *have* to interpolate.
Does
<<foo bar baz>>
mean
«foo bar baz»
or
('<foo', 'bar', 'baz>')?
* 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".
See the comment about 'fabulouser' above and add another 'and fabulouser' to the end.
* Multimethed references could be distinghuised either way:
&bark«Tree» &bark<Dog>
Good, so those of us who wish to use as much Unicode as possible can do so without having to rewrite the grammar. Excellent ;-)
* 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".
Unfortunately the ASCII equivalent doesn't have quite such a low profile, but I think I can live with that, since I can handle «» on all my Perl-coding systems. And the alternatives are still there for those who can't.
In many ways this seems clearer than the old way. I like it.
