|Is it the job of a parser to validate the input data? email@example.com (Roger L Costello) (2021-08-11)|
|Is it the job of a parser to validate the input data? firstname.lastname@example.org (Christopher F Clark) (2021-08-12)|
|Re: Is it the job of a parser to validate the input data? email@example.com (George Neuner) (2021-08-12)|
|Re: Is it the job of a parser to validate the input data? firstname.lastname@example.org (luser droog) (2021-09-03)|
|From:||luser droog <email@example.com>|
|Date:||Fri, 3 Sep 2021 21:37:53 -0700 (PDT)|
|Injection-Info:||gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="90378"; mail-complaints-to="firstname.lastname@example.org"|
|Posted-Date:||04 Sep 2021 16:54:43 EDT|
On Thursday, August 12, 2021 at 10:52:15 AM UTC-5, Christopher F Clark wrote:
> It is almost always done in the AST creation routines, not only do you
> as our insightful moderator mentioned generally get better error
> messages that way, but curiously, the features of extract a number,
> turn it into a count, and apply that count (and yes those might be 3
> distinct operations) to be how many items a list involves has not been
> implemented in any parser generator or lexer generator that I have
> ever seen. That's a bizarre omission, particularly since it is a
> common feature in many languages like networking protocols. Doing
> fixed counts isn't rare, but doing a count held in a "register" or
> "variable" seems to not be done.
I think the omission comes from difficulty in the formalization. Having to
apply such a dynamic count moves the parser from context-free to
context-sensitive, jumping to a new level in the Chomsky hierarchy.
So all the training wheels come off and it all gets scary.
Return to the
Search the comp.compilers archives again.