Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re^3: Unexpected parsing

by JavaFan (Canon)
on Dec 16, 2009 at 11:43 UTC ( #813007=note: print w/replies, xml ) Need Help??


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

I wonder if it might be appropriate for the precedence table to mention this unexpected (by me) interaction?
No, I don't think so. The ':' isn't an operator, so it has nothing to do with precedence. It doesn't belong in a precedence table. Determining whether something is an operator (or part of an operator) or not isn't dealt with with the operator precedence table.
Since the word ‘attribute’ does not occur in perlop or perlsyn, and since no other punctuation mark requires a visit to perlfunc to figure out how it parses
But you only find something about attributes in perlfunc because my was specially added to perlfunc; my isn't a function. The details are in perlsub, where you would also go for punctuation as prototypes and some cases of parenthesis.
Is there any unified list of officially undefined things?
Not that I know of. But by all means, feel free to write up a list and submit is as a patch. Writing documentation doesn't require any coding language, which means most people can do it.

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

    my isn't a function

    my is just as much a function as print. It just happens to have a compile-time effect too.

Re^4: Unexpected parsing
by JadeNB (Chaplain) on Dec 16, 2009 at 15:47 UTC
    But you only find something about attributes in perlfunc because my was specially added to perlfunc; my isn't a function. The details are in perlsub, where you would also go for punctuation as prototypes and some cases of parenthesis.

    Why do you say that my isn't a function? (I'm not arguing, just curious.) Do you mean it in the Lispy sense that it's a ‘special form’ (meaning, I suppose, that I couldn't write it myself in plain Perl)?

    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), not because it is itself an operator; but, aside from the fact that that idea probably doesn't make much sense on its own (should we mention every interaction of symbols?), what ikegami had said eventually sunk in and I realised that there's no reason to document the effect of trying to write officially undefined code.

    Not that I know of. But by all means, feel free to write up a list and submit is as a patch. Writing documentation doesn't require any coding language, which means most people can do it.

    The problem is that, as I say, I don't know the contents of such a list, and I'm not sure how I could figure it out. “Officially undefined” is basically an act of will on the part of the language designers; there's no way for me alone to tell the difference between “behaves this way but undocumented” and “behaves this way by chance, but is explicitly allowed to be changed on a whim”—because the difference is not in the code, but in the will of (I guess) the pumpking.

      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?

        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.

      "undefined" doesn't so much mean "is explicitly allowed to be changed on a whim". That's more along the lines of undocumented. It means bad stuff can happen if you do it.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://813007]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (8)
As of 2021-05-11 10:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Perl 7 will be out ...





    Results (116 votes). Check out past polls.

    Notices?