=> operator, not just fancy comma

[Matija Papec]

Clearly, it tries to quote its left side so third example goes apart from my
expectations and I'm wandering when should I worry over this arrow style.


original | B:eparse
-------------------------------------------------------------
@files = grep -d, @files; @files = grep(-d($_), @files);
@files = grep -d $_ => @files; @files = grep(-d($_), @files);
@files = grep -d => @files; @files = grep((-'d'), @files);

perl is v5.8.0

 

[Tad McClellan]

Clearly, it tries to quote its left side

Just like the docs say it does:

perldoc perldata


The C<< => >> operator is mostly just a more visually
distinctive synonym for a comma, but it also arranges for
its left-hand operand to be interpreted as a string--if
it's a bareword that would be a legal identifier.

 

[Anno Siegel]

Just like the docs say it does:

perldoc perldata


The C<< => >> operator is mostly just a more visually
distinctive synonym for a comma, but it also arranges for
its left-hand operand to be interpreted as a string--if
it's a bareword that would be a legal identifier.

In the particular case there's a little more going on. Matija pointed out
that autoquoting happens in

@files = grep -d => @files;

where "-d" is clearly not a legal identifier. "-" is treated specially
by "=>". The rationale for this behavior has never been quite clear to me,
but Tk users would have a hard time without it.

Anno

 

[Uri Guttman]

AS> @files = grep -d => @files;

AS> where "-d" is clearly not a legal identifier. "-" is treated
AS> specially by "=>". The rationale for this behavior has never been
AS> quite clear to me, but Tk users would have a hard time without it.

that is the rationale. the docs could use a tweak and state that => will
quote an identifier or one with a leading -. the 5.8 docs don't mention
the - which is a known feature but not documented AFAIK.

uri

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Uri Guttman

AS> @files = grep -d => @files;

AS> where "-d" is clearly not a legal identifier. "-" is treated
AS> specially by "=>". The rationale for this behavior has never been
AS> quite clear to me, but Tk users would have a hard time without it.

that is the rationale. the docs could use a tweak and state that => will
quote an identifier or one with a leading -. the 5.8 docs don't mention
the - which is a known feature but not documented AFAIK.

In

-d => @files

=> quotes the preceding identifier ``d'', resulting in

-'d', @files.

Since -'d' is '-d', one gets an illusion that it is ``-d'' which is quoted.

Hope this helps,
Ilya

 

[Uri Guttman]

IZ> -d => @files

IZ> => quotes the preceding identifier ``d'', resulting in
IZ> -'d', @files.

IZ> Since -'d' is '-d', one gets an illusion that it is ``-d'' which is quoted.
that makes no sense at all. look at this:


perl -le '%h = ( -d => 3 ); print keys %h'
-d

your definition of - should not be part of the key string
there. something is grabbing the - into the string and it is =>.

and check this out in the source:

case '-':
if (s[1] && isALPHA(s[1]) && !isALNUM(s[2])) {
I32 ftst = 0;

s++;
PL_bufptr = s;
tmp = *s++;

while (s < PL_bufend && SPACE_OR_TAB(*s))
s++;

if (strnEQ(s,"=>",2)) {
s = force_word(PL_bufptr,WORD,FALSE,FALSE,FALSE);
DEBUG_T( { PerlIO_printf(Perl_debug_log,
"### Saw unary minus before =>, forcing word '%s'\n"
, s);
} )
OPERATOR('-'); /* unary minus */
}

so -word is special cased with =>. it is not some random side effect.
i recall it wasn't that way but the tk crowd and others wanted it since
they use -word for keys all the time.

IZ> Hope this helps,

it didn't. sorry.

uri

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Uri Guttman

IZ> -d => @files

IZ> => quotes the preceding identifier ``d'', resulting in
IZ> -'d', @files.

IZ> Since -'d' is '-d', one gets an illusion that it is ``-d'' which is quoted.
that makes no sense at all. look at this:


perl -le '%h = ( -d => 3 ); print keys %h'
-d

your definition of - should not be part of the key string
there. something is grabbing the - into the string and it is =>.

I have no idea what you are talking about. Compare with ('-' . 'd' => 3)...

and check this out in the source:

case '-':

so -word is special cased with =>. it is not some random side effect.

You know how many special cases are in the Perl tokenizer, right?
Most probably this special case is there to compensate for ill effects
of some other special case.

To make tokenizer compatible with "preferences etc" of the parser is
very hard job; but for the users, who do not care about separation of
lexer/yaccer, this particular construct should be quite straitforward
- as I explained.

Hope this helps,
Ilya

 

[Tassilo v. Parseval]

Also sprach Ilya Zakharevich:

I have no idea what you are talking about. Compare with ('-' . 'd' => 3)...



You know how many special cases are in the Perl tokenizer, right?
Most probably this special case is there to compensate for ill effects
of some other special case.

As far as I understand the part of the tokenizer that Uri quoted, there
are actually a lot of different things going on in there.

Here it's a filetest operator:

%hash = (-e, 1);

and the checking for a following => is indeed a special case to not
confuse filetest operators and a string.

Here it is a string:

%hash = (- e, 1);

although there is no fat comma. If I can follow the code correctly, both

%hash = (-e => 1);

and

%hash = (- e, 1);

give the same result through different branches in the code. With the
fat comma

if (strnEQ(s,"=>",2)) {
s = force_word(PL_bufptr,WORD,FALSE,FALSE,FALSE);
DEBUG_T( { PerlIO_printf(Perl_debug_log,
"### Saw unary minus before =>, forcing word '%s'\n", s);
} );
OPERATOR('-'); /* unary minus */
}

is executed. Otherwise (the '(- e, 1)' case) the code falls through to
this branch around 90 lines later:

else {
if (isSPACE(*s) || !isSPACE(*PL_bufptr))
check_uni();
OPERATOR('-'); /* unary minus */
}

To make tokenizer compatible with "preferences etc" of the parser is
very hard job; but for the users, who do not care about separation of
lexer/yaccer, this particular construct should be quite straitforward
- as I explained.

Now that I had a slightly closer look at the tokenizer for the first
time, I agree with you. Its internals are insane so better look at it
from an end-user point of view.

Tassilo