09/02/07, demerphq <demerphq (AT) gmail (DOT) comwrote:
Although this reminds me,
STMT for keys %-;
STMT for keys %+;
Both warn about being ambiguous, which is annoying.
D:\dev\perl\ver\zoro\win32>perl -e"$x++ for keys %+"
Warning: Use of "keys" without parentheses is ambiguous at -e line 1.
The simplest fix for that is to tell scan_ident to avoid making this
check for hashes. It doesn't to it for $xxx, &xxx and @xxx
identifiers. Not sure why. Probably because there weren't many
punctuation hashes, and because % is also a binary operator. (but
again, & is, too.)
Untested, and I've not really thought about it:
/tmp/tmp.81624.0 Fri Feb 9 13:00:39 2007
/home/rafael/p4blead/toke.c Fri Feb 9 12:57:02 2007
@@ -4132,7 +4132,7 @@ Perl_yylex(pTHX)
Mop(P_MDUL);
}
PL_tokenbuf[0] = '%';
- s = scan_ident(s, PL_bufend, PL_tokenbuf + 1, sizeof
PL_tokenbuf - 1, TRUE);
+ s = scan_ident(s, PL_bufend, PL_tokenbuf + 1, sizeof
PL_tokenbuf - 1, FALSE);
if (!PL_tokenbuf[1]) {
PREREF('%');
}
Another issue, the NAME of named captures have similar constraints on
the name as identifiers - except that you cannot use '::' inside them.
That's a pity because with '::' there would be an obvious way of using
name spaces in your NAMEs.
I'm open to modifications of the naming rule so long as it ensures
that names are easy to parse and can't be confused with integers
(possibly signed) so that \g{} stays unambiguous.
So adding :: would be fine ? (or maybe a single char separator. But
we've already got _.)