Talk:Syntax checking/SRS
Janick
Please give some feedback regarding SRS so far
Manus
It is great. For the syntax validity, create an instance of EIFFEL_PARSER with the AST_NULL_FACTORY for the factory. That way it is quite efficient for the parsing.
manus 19:03, 2 May 2006 (CEST)
Janick
Manu, thanks for the feedback and hints.
Some people thaught that an timing-based parser would be better. Who is of the same opionion? Please use this discussion, as we need to finalize the specifications soon.
May 5th 2006 (CEST)
Martin
What exactly do you mean by timing-based? As specified in the SRS but with a timeout before it starts parsing or really independent of user input? I think it's good the way it is now (if it is efficient enough). Just a little remark to the notes: If the state of an expression can only change when the cursor leaves it, does that include the items under 1.1.1? I think it should, although I guess you should get a little time to resume typing.
Maser 23:57, 5 May 2006 (CEST)
Janick
Timing based would mean that the document gets parsed and highlighted in specific intervals (like every 50ms). This would also imply that while writing not yet completed feature names etc. would get underlined.
Stephan added that "when the cursor" leaves part, so he should answer that question. IMO if we have event-based parsing, that coursor leaves clause could be removed.
01:59, May 6th 2006 (CEST)
Martin
I've got a question to the interface section. Do you mean EDITOR_TOKEN or really the TOKEN class in the lex library? IMO it's not possible to do it this way, because the parser doesn't know that there is an editor. It can only generate a list of error descriptions, but cannot access the editor's data (if you use ec on the command line, there even is no editor whose data it could access). In a nutshell: the editor has to use the parser, not the other way around.
(should this be in the SRS as it concerns implementation?)
And something else: There can be syntax warnings (eg. when you use the word 'only' you get a warning that this could become a keyword in a future version of the language), so we can either ignore them (display nothing), treat them as errors (not a good idea) or use a different colour.
maser 02:16, 21 May 2006 (CEST)
