There are plenty of ways to get sub names or package names not known to the parser at the point where the parser encounters one of these barewords.

If it is not known to the parser, it cannot cause a parse conflict, and the lexical name prevails for the scope of the block in which it is defined. Existing convention discourages naming subroutines or packages in ALL UPPERCASE anyway, and I do not suggest changing that.

How is the parser to know that BAREWORD will eventually become PACKAGE, when the package is defined later?

I had just explained that the parser could recognize PACKAGE tokens because they contain at least one "::". An explicit "::" can be prefixed to top-level packages when needed or assumed when no parse conflict exists.

The desire to reduce indirect object notation is not primarily aesthetic; it's primarily because it's too often statically undecidable and it's fragile with regard to the action at a distance of what other code has been parsed and when.

That is a reason to adjust it to make it decidable, not to remove it entirely. Lexical bareword filehandles preserve (most) compatibility while removing (at least some) parse ambiguity: a lexical bareword filehandle parses as VARIABLE rather than BAREWORD. Similarly, recognizing barewords containing "::" as PACKAGE tokens disambiguates class method calls.

if I name a bareword filehandle JSON or YAML because I'm going to read or write some structured data, I don't want my program to behave unpredictably depending on when the modules of the same name get loaded.

This proposal does not have that problem — within the scope of a JSON or YAML filehandle, those tokens are variable references rather than package names, but could still be disambiguated as ::JSON or ::YAML to get a PACKAGE token if you wanted to call a class method while inside such a scope. (Note that in the scope of open JSON,..., JSON->new would parse as a method call on the {I/O}JSON variable because part of the proposal is for indirect object and arrow notations to be equivalent.)

In reply to Re^2: On Backwards Compatibility and Bareword Filehandles by jcb
in thread On Backwards Compatibility and Bareword Filehandles by jcb

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.