in reply to Unquoted hash slice keys with use strict 'subs'

It has nothing to do with danger. It's a parsing/tokenizer thing. An unquoted string that looks like an identifier is a single token. The next token is the curly brace - so with one lookahead token, perl can determine it's a bareword that needs autoquoting. But if it sees a comma, it doesn't know what's happening - it cannot say "hmmm, I saw an opening curly brace, a bare word, a comma, perhaps it's a list, let's just see if it's a list of bare words all the way until the closing brace, if something else happens, I just backpaddle and try something else".

If you do want perl to parse $hash{key1,key2,key3}, just turn off use strict 'subs'.

Replies are listed 'Best First'.
Re^2: Unquoted hash slice keys with use strict 'subs'
by cdarke (Prior) on Oct 14, 2009 at 11:28 UTC
    You might be right - I have no knowledge of the complexities of the parse order - but I would have thought that the comma would not be unexpected because of the @ sigil. Surely, knowing that the clause inside the curley braces is in list context it would be expecting a list, a comma shouldn't come as any surprise.
    The error message reports three bare words, so it knows what the comma is and it recognises them as a list, it seems though it ignores the sigil and the braces.
[reply]
      It may know what the comma is, it doesn't know what follows the comma.
[reply]
Re^2: Unquoted hash slice keys with use strict 'subs'
by ikegami (Patriarch) on Oct 14, 2009 at 14:46 UTC

    I don't think any backpedaling would be necessary if you want 

    $hash{foo,bar}   =>  $hash{'foo','bar'}
$hash{foo,bar()} =>  $hash{'foo',bar()}

    [download]

    Or are you saying you should get something else from the second line?

    By the way, Perl's parser is an LR parser, and they can't backpedal.

[reply]
[d/l]

In Section Seekers of Perl Wisdom