3 ms·
That's why C is usually parsed with a symbol table, which is the way it was meant to be parsed. When parsing "foo * bar;", then it should be clear after parsing
by jstimpfle 8y ago
That's why C is usually parsed with a symbol table, which is the way it was meant to be parsed. When parsing "foo * bar;", then it should be clear after parsing "foo" whether the statement is a variable declaration or an expression syntax. (It's a variable declaration if "foo" is registered as a type in the symbol table).
The advantage of this style is that types align nicely to the left and no additional keywords (like let) are required. The disadvantage is that parsing becomes highly contextual. We can't start with parsing somewhere in the middle of a file.
- thedufer 8y agoThat seems insufficient - what if foo is both a type and a variable?
- colanderman 8y agoIt can't be. (Additionally, in C++, where `struct/enum/class foo` can be shortened to `foo`, the variable interpretation is always preferred.)
- millstone 8y agoMostly it just seems silly to use * for both pointers and arithmetic. We're not hurting for sigils even in ASCII.
- jstimpfle 8y agoIn C, for example dollar-sign and at-sign are unused and could be used for pointers. But I don't like those. Both are visually clunky characters. Personally I like how it is in Pascal - caret sign for pointer types, and postfix unary operator caret for dereference, like^.this which doesn't need an additional syntax ( like->this is just (* like).this in C). But now, caret is usually also the XOR operator. The deeper problem is that Pascal cannot use caret as XOR binary operator since postfix operators cannot easily be distinguished from binary operators with only 1 token lookahead - it would require more lookahead or type resolution to determine that it's not a binary operator. While in C the deref operator is a prefix which can be distinguished from binary operators without lookahead.