Talk:Irony - Language Implementation Kit/Grammar/Terminals

Hi

Great start! A few comments: I suggest to provide Overview chapter with a few pages before you start with particular terminals.

1. Parsing process overview - BNF, grammar, parser, scanner concepts, different parsing algorithms, LALR(1) algorithm used in Irony. Different approaches to parser construction (traditional - code generation from grammar descirption- Lex/Yacc)

2. Irony parser construction - outline the process, how to define a grammar (transliterate from BNF), define language elements in grammar constructor, grammar rules, etc. Parsing process: source->tokens->ParseTree->AstTree (optional). Grammar Explorer - what's it used for. Have a look at my CodeProject article, it is outdated as for sample code, but it contains some introductory information like this

3. Quick end-to-end sample. Or maybe overview of expression evaluator grammar.

Specific comments

0. "Terminals are the tokens.." - this is a bit incorrect; Termianals are token recognizers, they are not tokens themselves, they produce tokens. It would help to provide an overview of the Terminal class, and its TryMatch, GetFirsts methods; some important properties like Priority, Precedence, Associativity

1. CommentTerminal - all comment terminals MUST be added to NonGrammarTerminals set, it is not a choice of developer. The reason is that comments are not mentioned explicitly anywhere in grammar rules, but Irony needs to know that they are there, so NonGrammarTerminals set is just for this purpose

2. Use "var" keyword in sample code when declaring variables; it is a good practice in .NET. Like var comment = new CommentTerminal(...);

3. Use standard .NET practices in variable names; local variables should be camelCase, so use lineComment instead of LINE_COMMENT

4. Many of Irony standard terminals have extended config options, and they should be described in details (in the future). Considering this, I think it is better to have a separate page for each

5. Example in keyword terminal is a bit misleading: selectStatement.Rule = ToTerm("select") + optionalSelectArgs + ToTerm("from") + ... + ToTerm(";"); The fact is - you don't need to use ToTerm here, you can use the literal directly; we should encourage this style - direct use of literals, so we should put this example first in this section

6. About Date literal; DataLiteralBase - it is a base (abstract) class ("Base" indicates this) It should not be instantiated directly, only subclassed; it is base for two other classes. I did not make it abstract explicitly, but essentially it is. It is not created particularly for scanning dates. Both DsvLiteral and FixedLengthLiteral can be used to scan dates - along with other types

thanks

Rivantsov (talk) 18:20, 12 June 2010 (UTC)