On Tue, 30 Nov 2004, Larry Wall wrote:
> 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.
My biggest worry about this is that people will be writing
if $x<3
loop( $x=0 ; $x<10 ; $x++ )
more than occasionally.
> * We steal angles away from iterators.
I vote we do that in any case.
> 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>
I'm starting to like $var{'key1'}{'key2'}[3]{'key3'} more and more.
And it's the only way to write $var{'key with spaces'}, right?
> * That means that, roughly, we have this proportion:
>
> '...' : "..." :: <...> : �...�
That's definitely worth a cuteness award.
> Now with those out of the way, the good news:
> * All other uses of �...� and <...> swap, pretty much.
Moving this to the end, because I want to request clarification in the
context of rules.
> * Match vars become $<foo> instead of $�foo�.
>
> * A rule like <ident> now captures, while �ws� or <<ws>> doesn't.
Is all the "Extensible metasyntax (<...>)" being changed to �...� ?
Or is the new rule that <...> is capturing metasyntax, and �...� is
non-capturing metasyntax?
Does / <-<alpha>> / capture to $0{'-<alpha>'} ?
Or should that be written / <-�alpha�> / ?
You can't really capture anything on an assertion, so
/^foo .* <( do { say "Got here!" } or 1 )> .* bar$/
is probably not an issue at all.
How are the results different between these?
/<ident>/
/(<ident>)/
/(�ident�)/
~ John Williams
