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 WilliamsThread Previous | Thread Next