Hacker News Reader

Comment by Animats | Hacker News Reader

It's a historical problem in C. Originally, C had only built-in types. Structs were declared with

    struct foo { int x; int y; };

which is easy to parse. Then came typedef. With user-defined types,

    foo*bar;

isn't parseable with a LALR(1) parser until you've seen the definition of "foo". Even the ordinary case

    foo bar;

needs more than one lookahead to parse. This is a headache for compilers, and a huge headache for anything that wants to work on single source files without seeing the included files.

It's a big win if files are parseable without their dependencies. The Pascal/Modula/Ada family all are. I think Go is. Not sure about Rust, but it probably is. C and C++, no.

(The hacks for template syntax in C++ are painful to think about.)

View on HN

Yeah, the easiest way to do it is return a different token type from the lexer for type names, which means the lexer looks up the symbol table when it sees identifiers.

Amusingly, the Delphi dialect of Pascal has an ambiguity in its grammar from how it made function pointers work:

    function g: Integer;
    // ...
    f(g);

Depending on the definition of f, this could be passing the function f by reference (as a function pointer), or passing the result of calling f.

Delphi looks at the argument type to resolve the ambiguity, but it stays awkward in overload scenarios, when there's a choice between Integer or function pointer arguments.

At some point around about 2009, I added the ability to specify explicitly that you want the call, to eliminate the ambiguity:

    f(g());

> Not sure about Rust

Rust has made a point of being parser-friendly, to support tooling. The entire reason the turbofish ::<> exists is to avoid ambiguous grammar. (This operator seems to vex people, I don't get the hate.)

Being parser-friendly is not at all the same thing as being user-friendly. The difficulty of writing parsers is way overblown.

One thing to avoid is depending on the existence of the symbol table to parse correctly. (C++ has this problem.) Needing a symbol table makes it hard for parsers like source code formatting and syntax highlighting.

Another is to avoid raw string literals that reach back and try to unwind the results of previous "phases of translation".

Agree with a caveat; if the syntax has many ambiguities, with resolution solved by a clever parser, it'll be confusing for users, especially newbies, because they'll tend to get errors unrelated to what they were trying to achive.

Redundancy in syntax can be a bonus.

> Redundancy in syntax can be a bonus.

I agree. I even wrote an article about that:

https://www.digitalmars.com/articles/b05.html

Both humans and computers parse code. Humans can handle ambiguity mode easily than computers, but that doesn’t make the ambiguity more user friendly somehow.

Do note that Rust the language is regular and easy to parse, but rustc the compiler actually performs bounded lookahead and contextual parsing on parse errors to detect common typos and invalid syntax that would otherwise be vexing to users. The nightly only type ascription : syntax is a good example because it crops up in several different contexts as a 1-substitution typo and used to be terrible (may it burn in a fire). The turbofish is another case where we now suggest the correct syntax, but there are many, many more.

Surely that's an example of how parser-friendly syntax empowers tooling? I imagine that it would be much harder to guess intention and fixes from lookahead and context if those were already necessary to make sense of correct code?

I love the turbofish so much, not because it looks nice in code or anything, but because the name is a bit of harmless fun that makes the language feel inviting.

Ah, C not originally having typedefs explains why the syntax wasn't thrown out as too annoying to begin with. Syntax creep I guess.

An easy solution to the problem would be to do what e.g. Haskell does where case-sensitivity determines a type name. For better or worse, C didn't do that.

In Dylan all types were delimited with <angle_brackets>. Personally I always found that very aesthetically pleasing.

Same in Powershell except they use square brackets

[string] $foo = "foo"

In my brain the instantly translates to "list of strings". Not sure square brackets are such a good choice.

On the other hand doesn’t forward declaration make sense? The code is declaring it depends on the forward declaration defined “somewhere else”. In a sense it is documenting the the classes/structs better.

Years ago, I stumbled upon a Visual C++ 6.0 bug (if memory serves me right), just by playing around trying to understand C/C++ decls. It would crash on a stray:

*c;

at the beginning of a translation unit.

Didn't K&R have a tiny, tiny C declarations parser (printing out 'human readable' equivalents) example in their book? I think the caveat was that it needs to assume it's dealing with a declaration...

Reply on news.ycombinator.com