Related articles |
---|
Is it the job of a parser to validate the input data? costello@mitre.org (Roger L Costello) (2021-08-11) |
Is it the job of a parser to validate the input data? christopher.f.clark@compiler-resources.com (Christopher F Clark) (2021-08-12) |
Re: Is it the job of a parser to validate the input data? gneuner2@comcast.net (George Neuner) (2021-08-12) |
Re: Is it the job of a parser to validate the input data? luser.droog@gmail.com (luser droog) (2021-09-03) |
From: | luser droog <luser.droog@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Fri, 3 Sep 2021 21:37:53 -0700 (PDT) |
Organization: | Compilers Central |
References: | 21-08-011 |
Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="90378"; mail-complaints-to="abuse@iecc.com" |
Keywords: | parse, semantics |
Posted-Date: | 04 Sep 2021 16:54:43 EDT |
In-Reply-To: | 21-08-011 |
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
comp.compilers page.
Search the
comp.compilers archives again.