[HN Gopher] A most vexing parse, but for Python packaging
       ___________________________________________________________________
        
       A most vexing parse, but for Python packaging
        
       Author : woodruffw
       Score  : 37 points
       Date   : 2022-05-09 14:24 UTC (8 hours ago)
        
 (HTM) web link (blog.yossarian.net)
 (TXT) w3m dump (blog.yossarian.net)
        
       | abbeyj wrote:
       | I have a minor complaint about an otherwise enjoyable article.
       | You introduce the term "bdist" and define it but then introduce
       | the term "wheel" without defining it or explaining how it is
       | different from "bdist". You mostly use the term "wheel" for the
       | rest of the page so I'm wondering if you need to introduce the
       | term "bdist" at all.
        
         | woodruffw wrote:
         | Thanks for catching that! That's an editing mistake: I was
         | originally going to introduce wheels as the primary kind of
         | bdist that we're interested in, but I decided that it would be
         | too much of a tangent. I'll rewrite that section now.
         | 
         | Edit: I've added some language to clarify that "bdist" and
         | "wheel" are interchangeable in the context of the post.
        
       | bruce343434 wrote:
       | The most vexing parse is not an issue in "C and C++ grammars", it
       | is only an issue in C++ which has really stupid initialization
       | syntax that looks like a function call.
       | 
       | C and C++ are not the same language nor even that similar. It's a
       | shame they are always mentioned together under the same breath.
        
         | pdmccormick wrote:
         | If I ever see a resume or a job description that lists "C/C++",
         | that's a red flag to me that either someone might not actually
         | have that much experience, or someone doesn't actually know
         | what they are looking for.
        
           | woodruffw wrote:
           | IME, people who list "C/C++" on their resumes tend to be
           | recent undergraduates. When asked about it, they usually have
           | C experience from one or two systems courses, and C++
           | experience from a separate course. Undergraduate courses tend
           | to teach C++ as an "extension" of C because it eliminates the
           | hump (and anxiety) of teaching an entirely new language, at
           | the cost of being technically misleading.
        
         | woodruffw wrote:
         | Author here: the examples in the blog post are for C++, but a
         | variant of the MVP also occurs in C when uniform declaration
         | interacts with typedefs. Here's an old (1992!) comp.compilers
         | post on it[1].
         | 
         | [1]: https://pdos.csail.mit.edu/archive/l/c/roskind.html
        
           | planede wrote:
           | I would say that these are context-sensitive, but it doesn't
           | seem to be analogue to C++'s most vexing parse. In the most
           | vexing parse case all identifiers are resolved to the correct
           | kind (type name or variable name), yet it is still ambiguous.
           | The C examples are unambiguous after the kind of the
           | identifiers are identified.
           | 
           | A C exmaple:                  T(*ptr)[42];
           | 
           | If T is a type then this is a declarations of a pointer to an
           | array of T. If T is a function, then this is a function call
           | followed by a subscript (which is then discarded).
           | 
           | A similar C++ analogue would be:                   C<0>(0);
           | 
           | If C is a function template with a non-type template
           | parameter, then this is a function call of C<0> with argument
           | 0. If C is an int variable instead then it is equivalent to
           | the following expression (C < 0) > 0 .
           | 
           | But for T a(); in both possible interpretations T is a type,
           | and 'a' is the new entity being declared. So parsing this is
           | not context-sensitive, it's simply ambiguous. C++ resolves
           | the ambiguity by choosing in favor of function declarations.
           | I'm not aware of a C analogue similar to this.
        
             | woodruffw wrote:
             | To be clear: I'm not claiming they're analogous, only that
             | they're both consequences of uniform declaration and are
             | historically grouped together when talking about "vexing
             | parses."
        
       ___________________________________________________________________
       (page generated 2022-05-09 23:02 UTC)