develooper Front page | perl.perl5.porters | Postings from February 2013

The allow_initial_tick argument to force_word()

Thread Next
Nicholas Clark
February 26, 2013 21:03
The allow_initial_tick argument to force_word()
Message ID:
I believe that this is now redundant, and can be removed.

It was set to TRUE in 3 places.

The only remaining call is this one:

		if (key == KEY_format) {
#ifdef PERL_MAD
		    PL_thistoken = subtoken;
		    s = d;
		    if (have_name)
			(void) force_word(PL_oldbufptr + tboffset, WORD,
					  FALSE, TRUE, TRUE);

That code was "added" by commit 09bef84370e90d72, "sub : attrlist", back in
1999. At that call site, S_force_word() is only called for formats, not for
subroutines. For parsing formats, it doesn't matter whether it's TRUE or

The other 2 remaining call sites with TRUE were removed by commits
4210d3f17cf9d854 and 764212cf73683dc2 in 2012.

(eg run --match '^\t\t\(void\) force_word\(PL_oldbufptr' toke.c

If I change *those* from TRUE to FALSE then this code example stops parsing:

./miniperl -e "sub 'foo {warn qq{ok}}; &'foo"

I think that the difference is that in perly.y formats are formname, which is

formname:	WORD		{ $$ = $1; }
	|	/* NULL */	{ $$ = (OP*)NULL; }

whereas subroutines are subname, which is

/* Name of a subroutine - must be a bareword, could be special */
subname	:	WORD

and I *infer* that PRIVATEREF can manage to get confused by the leading '

But at this point I'm well out of my depth.

Anyway, I think that the upshot is that

a) the last parameter to S_force_word() can be dropped, because it's
   effectively false at all times.
b) even if I'm wrong, it's only going to break some really obscure Perl 4
   era code that uses single quote package separators and formats.

Nicholas Clark

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About