Related articles |
---|
Supporting multiple input syntaxes mijoryx@yahoo.com.dmarc.email (luser droog) (2020-08-12) |
Re: Supporting multiple input syntaxes 793-849-0957@kylheku.com (Kaz Kylheku) (2020-08-13) |
Re: Supporting multiple input syntaxes DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2020-08-13) |
Re: Supporting multiple input syntaxes minforth@arcor.de (2020-08-13) |
Re: Supporting multiple input syntaxes mijoryx@yahoo.com.dmarc.email (luser droog) (2020-08-13) |
Re: Supporting multiple input syntaxes mijoryx@yahoo.com.dmarc.email (luser droog) (2020-08-13) |
Supporting multiple input syntaxes davidlovemore@gmail.com (David Lovemore) (2020-08-15) |
Re: Supporting multiple input syntaxes mijoryx@yahoo.com.dmarc.email (luser droog) (2020-08-15) |
Re: Supporting multiple input syntaxes davidlovemore@gmail.com (David Lovemore) (2020-08-16) |
Re: Supporting multiple input syntaxes mijoryx@yahoo.com.dmarc.email (luser droog) (2020-08-20) |
Re: Supporting multiple input syntaxes gah4@u.washington.edu (gah4) (2020-08-23) |
Re: Supporting multiple input syntaxes mijoryx@yahoo.com.dmarc.email (luser droog) (2020-08-23) |
Re: implementation languages, was Supporting multiple input syntaxes mijoryx@yahoo.com.dmarc.email (luser droog) (2020-08-23) |
Re: Supporting multiple input syntaxes mijoryx@yahoo.com.dmarc.email (luser droog) (2020-08-23) |
[8 later articles] |
From: | luser droog <mijoryx@yahoo.com.dmarc.email> |
Newsgroups: | comp.compilers |
Date: | Sat, 15 Aug 2020 15:20:06 -0700 (PDT) |
Organization: | Compilers Central |
References: | 20-08-002 20-08-009 |
Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="85278"; mail-complaints-to="abuse@iecc.com" |
Keywords: | parse, errors |
Posted-Date: | 15 Aug 2020 19:00:31 EDT |
In-Reply-To: | 20-08-009 |
On Saturday, August 15, 2020 at 9:46:47 AM UTC-5, David Lovemore wrote:
> It may be useful to consider what you would like to happen if you encounter a
> syntax that is ambiguous or works differently or is for another expected
> syntax from what you are parsing: produce a warning, error or handle quietly,
> or fall over, or don’t care.
Very good points. The parser is backtracking, returning a list of
results. That could conceivably be useful for dealing with ambiguity by
looking at more than just the first result.
Warnings and error messages are going to be trickier I fear. The parser
is built around the idea of Monadic combinators. So my research suggests
that I'll need Monad Transformers to add the state needed for good
messages. There are a bunch of lectures I've found about using these
in Haskell, but not much about how to build them from scratch.
As it is, any error in parsing will just produce no results.
I started a prototype where the input list of characters was instead
a list of (character, line-number, line-position). But it got really
confusing at the time so I stopped. And the few times I've tried to
look at it, I can't figure out what I was thinking.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.