| |||||||||||||
Why learn C? (O'Reilly Radar)Why learn C? (O'Reilly Radar)Posted Jun 30, 2012 17:48 UTC (Sat) by tjc (subscriber, #137)In reply to: Why learn C? (O'Reilly Radar) by HelloWorld Parent article: Why learn C? (O'Reilly Radar)
> signal(int, *(int)void) *(int) void
That's going to be hard to parse. The lexer is going to return a token with the value "signal", but the parser is going to be sitting at the top level without any context in which to evaluate it. If it's not a reserved word then it must be an identifier, but nothing else is known about it without peeking further ahead into the input stream.
Something like this would be more practical:
func signal(int, *(int)void) *(int)void
I personally don't mind that C (and C-like languages) anchor declarations with the type. It's still a left-to-right parse, with the single exception of the type. The "var|func ... <complete return type>" syntax is probably better, but I've been looking at "<type> ..." for so long that it seems natural to me. It also allows you to do things like this:
int i, j;
As far as the foo * vs. foo[] thing, that's not really a syntax problem, it's a semantic problem, given that arrays decay to a pointer to the first element in most (but not all; e.g. sizeof(foo)) cases. I agree that that could be changed, and it would be better in most cases. I usually write array parameters as foo *, just because that's what they really are inside the function.
I'm not aware of the difference between a switch statement and a switch expression, so I can't comment on that. I guess I better start "googling."
(Log in to post comments)
Why learn C? (O'Reilly Radar) Posted Jul 1, 2012 11:15 UTC (Sun) by HelloWorld (guest, #56129) [Link]
> That's going to be hard to parse. The lexer is going to return a token with the value "signal", but the parser is going to be sitting at the top level without any context in which to evaluate it. If it's not a reserved word then it must be an identifier, but nothing else is known about it without peeking further ahead into the input stream.
I fail to see how conventional C syntax is any better. In a declaration such as foo *bar;, you have exactly the same situation, and to be honest, I don't even see why it's supposed to be a problem.
The only problem I see with this syntax is that it's ambiguous: there's no way to know whether foo(bar)*baz; is a declaration or a statement without looking at the preceding declarations in order to find out whether bar and baz are variables or typedef-names. Alas, conventional C syntax has the same problem in declarations such as the above-mentioned foo *bar;.
It's also fairly easy to disambiguate it using a syntax such as
Why learn C? (O'Reilly Radar) Posted Jul 1, 2012 22:30 UTC (Sun) by tjc (subscriber, #137) [Link]
I can't think of a situation in C where an expression that begins with a type specifier is anything other than a declaration. I could be overlooking something, but I'm looking at the grammar in appendix A13 of K&R, and I don't see anything.
Why learn C? (O'Reilly Radar) Posted Jul 1, 2012 22:49 UTC (Sun) by HelloWorld (guest, #56129) [Link]
> I can't think of a situation in C where an expression that begins with a type specifier is anything other than a declaration.
Uh, so? In a declaration like foo *bar, you still have to know whether foo is a typedef or a variable name in order to know whether it's a multiplication or a declaration.
Why learn C? (O'Reilly Radar) Posted Jul 1, 2012 23:02 UTC (Sun) by tjc (subscriber, #137) [Link]
The compiler has this information available to it in the symbol table.
Why learn C? (O'Reilly Radar) Posted Jul 1, 2012 23:20 UTC (Sun) by HelloWorld (guest, #56129) [Link]
I know, this is the well-known lexer hack. I still don't see how the syntax I've proposed is supposed to be any more problematic than conventional C syntax.
Why learn C? (O'Reilly Radar) Posted Jul 2, 2012 20:36 UTC (Mon) by tjc (subscriber, #137) [Link]
The type specifier in a C declaration acts as a surrogate for the missing 'var' or 'func' keyword, which makes it possible for the parser to recognize the declaration without requesting a lot of extra tokens from the lexer.
Why learn C? (O'Reilly Radar) Posted Jul 2, 2012 21:23 UTC (Mon) by HelloWorld (guest, #56129) [Link]
I think that this is only a problem when using top-down parsers. A bottom-up parser should handle this situation easily.
Why learn C? (O'Reilly Radar) Posted Jul 3, 2012 15:46 UTC (Tue) by tjc (subscriber, #137) [Link]
Yes, it could be made to work, but it would have to be a backtracking parser, and it would probably be slow. Most bottom-up parsers (such as those produced by bison) are LALR(1), which only has one token look-ahead.
Why learn C? (O'Reilly Radar) Posted Jul 1, 2012 22:59 UTC (Sun) by tjc (subscriber, #137) [Link] I wish there were some way to edit posts after posting so that my mistakes are not permanently recorded for posterity. :)I should have said, "I can't think of a situation in C where a statement that begins with a type specifier...."
Why learn C? (O'Reilly Radar) Posted Jul 2, 2012 9:30 UTC (Mon) by nix (subscriber, #2304) [Link]
Quite, thus ruling out sizeof().
|
|||||||||||||