Compiler Construction by Niklaus Wirth [pdf]

Re:Compiler Construction by Niklaus Wirth [pdf] by beagle3 on Saturday February 01, 2020 @06:38PM (#22214028)

C has a lot of things which are context sensitive, and you can't treat the casting type as an expression:

    c*(a)-b

parses under (double a, b, c;) as ((ca)-b) ; but under (typedef double a; double b, c) it parses as c-b, (with a type conversion applied after the negation) which is a different parse, and which can be more complicated than that to the point that fixing the AST is equivalent to reparsing the source.

Use before declaration can only be resolved at the typechecker if you assume every name is a variable, but the introduction of typedefs makes that assumption wrong, so you can't wait for the type checker - every C parser I know patches that information back into the lexer so that it would parse correctly. Indeed, the "typename" keyword was added to C++ because you can't leave that to the typechecker if you want a unique parse before instantiation.

[ Parent | on HN ]

Re:Compiler Construction by Niklaus Wirth [pdf] by seanmcdirmid on Saturday February 01, 2020 @07:00PM (#22214151)

Parsing with type information is not the norm. It was only done in C because no one knew any better back then. Later language that adopt C-style casting (C#, Java) do not need to know if something is a type to deal with parens, they look for the follow on and evaluate the tree accordingly. That is why in C#:

  var x = (Foo) - foo;

Will be rejected with a type error (must enclose -foo in parentheses because Foo is a type) rather than a parse error.

[ Parent | on HN ]