A most vexing parse, but for Python packaging | Hacker News Reader

A most vexing parse, but for Python packaging

blog.yossarian.net

42 pointswoodruffw9 comments

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.

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

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.

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."

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.

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.

You will find plenty of those from the job boards of the companies that seat at ISO C++, and their SDK documentation.

Once upon a time, "The C/C++ Users' Journal" was the reference magazine for C and C++ developers.

As per English grammar rules, / is an abbreviation,

https://eslgrammar.org/forward-slash/

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.

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.

Reply on news.ycombinator.com