Re: Supporting multiple input syntaxes

luser droog <mijoryx@yahoo.com.dmarc.email>
Sat, 15 Aug 2020 15:20:06 -0700 (PDT)

          From comp.compilers

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]
| List of all articles for this month |
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.



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.