The semantic parser is a combination of what might think of as a
compiler's parser, and an iterative loop.
A traditional compiler will sometimes spit out the warning:
"too many errors, giving up."
This is because it gets lost in the source file due to perhaps a
missing { or }, and it can't figure out what is going on.
To avoid this problem in semantic, the portion of a traditional
compiler that identifies multiple top-level nonterminals (functions,
variables, etc) is left out of the grammar, and is handled in Emacs
Lisp code instead.
What this means is if you start parsing at a given point in the
buffer, if the grammar completely fails to identify anything, that
parse step exits with out using any lexical tokens. When this
happens, the Iterative Emacs Lisp looper marks that bit of syntax as
unmatched, moves forward 1 lexical token, and tries again.
That way, if you have a stray "foo" floating in between methods, it
gets labeled as unmatched. A traditional parser usually can find this
error and move on as well, but the support structure needed for error
handling in a traditional grammar file is much more complicated.
David Ponce wrote a nice piece describing the differences in the
wisent parser generator manual currently residing in Semantic's CVS
repository.
Enjoy
Eric
>>> "Chitale, Sandip V" <[EMAIL PROTECTED]> seems to think that:
>Eric,
>
> Can your or someone explain what the term
>"unmatched syntax" means ? Does it mean syntax errors ?
>Does it mean syntax and semantic errors ? Does it mean
>all the compilation errors ?
>
>thanks,
>sandip
>
>> -----Original Message-----
>> From: Eric M. Ludlam [mailto:[EMAIL PROTECTED]
>> Sent: Friday, February 21, 2003 10:10 AM
>> To: Berndl, Klaus
>> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>> Subject: Re[1]: FW: Syntax error indication on the fly....
>>
>>
>> Semantic only shows unmatched syntax for definitions. All
>> code that resides inside the body of a function is skipped
>> over. This is to make parsing go faster.
>>
>> Semantic 2.0 CVS includes a full Java parser. My assumption
>> is that it could then do unmatched syntax for all the code,
>> though I am not sure how to turn it on. That is something
>> David Ponce could better answer.
>>
>> Eric
[ ... ]
--
Eric Ludlam: [EMAIL PROTECTED], [EMAIL PROTECTED]
Home: http://www.ludlam.net Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: www.gnu.org
