Timeline for parsing at semantic level due to ambiguities
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 23, 2014 at 9:07 | comment | added | babou | @Val Note that it is possible for a language definition to allow for ambiguities that cannot be resolved by semantics. But then, the mabiguity must be detectable by the compiler and produce an error message, so that the programmer is required to add to the program appropriate information (such as type information) that will resolve the ambiguity (search the web with: ada ambiguity). This is not necessarily a syntactic ambiguity (what is syntactic?), but syntactic ambiguity could be treated the same way. Language designers tend to try avoiding it, though. | |
| Apr 23, 2014 at 8:50 | comment | added | babou | @Val There is no absolute rule on how to organize a compiler or interpreter. Most languages are built in such a way that lexical items can be associated with a prior definition allowing to know whatever is needed for parsing. This information is used by the lexer. What kind of information depends on the language. Building a parse tree is not usually an issue as grammars (hence parse-trees too) are often tortured to fit a parsing technique. What may be useful is building an abstract syntax tree (AST) that is close to the language semantics. But this may use lexer information (when possible). | |
| Apr 23, 2014 at 5:41 | comment | added | Val | So, you say that the elaboration can be integrated into the parsing. That is a good argument. I actually see no reason to build the parse tree since it seems to me that VHDL can be elaborated in single pass. If it aids the parser, this is one additional argument to avoid creating extra structures. Thanks. | |
| Apr 22, 2014 at 21:11 | history | answered | babou | CC BY-SA 3.0 |