in reply to Re^4: Unexpected parsing
in thread Unexpected parsing

Why do you say that my isn't a function?
Because, IMO, functions take values (even if they are references or aliases), do something when called at runtime, and return zero or more values.

But for my, things are different. Its effects are mostly at compile time. It takes names, not values (if something takes values, you can replace the value with any expression returning said value). There's no prototype for my. The only things that act like my are local, our, and to some extent, state. None of them are functions. return isn't a function either.

I was just suggesting that :-for-attribute-list could be mentioned in perlop because it affects parsing (which is, after all, what one is trying to figure out when looking at a precedence table)
Uhm, is there any token that doesn't affect parsing in some way? If you're going to add colons, why not semi-colons? Braces?

Replies are listed 'Best First'.
Re^6: Unexpected parsing
by ikegami (Patriarch) on Dec 16, 2009 at 17:08 UTC

    Because, IMO, functions take values (even if they are references or aliases), do something when called at runtime, and return zero or more values.

    At runtime, It takes the name of a variable, allocates it* and returns the named variable as an lvalue.

    * — The implementation differs, but this is the intent of my and it should be the perceived effect.

    return isn't a function either

    It is a function. It's not a function in the functional programming sense — it has side-effects — but that's not relevant here.

    More specifically, perlfunc documents named operators, and return is one.

    If you're going to add colons, why not semi-colons? Braces?

    Semicolons can't appear in expressions. As for braces, both constructs such as do {} and the anon hash contructor *are* mentioned in perlop.