Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #2564
| From | luser droog <mijoryx@yahoo.com.dmarc.email> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: Supporting multiple input syntaxes |
| Date | 2020-08-20 14:45 -0700 |
| Organization | Compilers Central |
| Message-ID | <20-08-012@comp.compilers> (permalink) |
| References | <20-08-002@comp.compilers> <20-08-009@comp.compilers> <20-08-010@comp.compilers> <20-08-011@comp.compilers> |
On Sunday, August 16, 2020 at 10:53:24 AM UTC-5, davidl...@gmail.com wrote: > My friend, reporting the furthest position examined by the parser I have [found] > useful in error cases as a simple stop gap when using a combinator approach. > > Thinking about it you kind of want to see the furthest failed position and the > stack of rules above it. Such requires meta information when the code is > written in the most natural way. For this reason and others I believe it is > good to represent your grammar in data structures which is further in the > direction of a compiler compiler tool (or compiler interpreter tool). Thanks. I've done some further investigating. I built my parsers following two papers. Hutton and Meijer, Monadic Parser Combinators https://www.cs.nott.ac.uk/~pszgmh/monparsing.pdf and Hutton, Higher-Order Functions for Parsing https://pdfs.semanticscholar.org/6669/f223fba59edaeed7fabe02b667809a5744d9.pdf The first adds error reporting using Monad Transformers. I'm thinking about how to move in this direction, but first I'd need to reformulate the code to make the Monad more explicit. It should be something like an interface or a mixin, like a base class with all virtual member functions. That could be done by modelling my objects more like OO objects and have 'bind' and 'result' in a vtable in the Parser object. But the second paper does it differently, and maybe something I can do more easily. It redefines the parsers to no longer produce a list of results, so there's no longer support for ambiguity. Then it defines them to return a Maybe, maybe * ::= Fail [char] | Error [char] | OK * . where the OK branch has the parse tree, and Fail or Error both contain an error message. It describes how a Fail can be transformed into an Error. But it isn't entirely clear where the messages get injected. Still need to do some thinking on it, but I think I can rewrite the parsers to follow this model, and then decorate my grammar with possible errors at each node. Thanks for the encouragement. My classes start on Monday so I'm hoping to accomplish something on this before then.
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar
Supporting multiple input syntaxes luser droog <mijoryx@yahoo.com.dmarc.email> - 2020-08-12 15:20 -0700
Re: Supporting multiple input syntaxes Kaz Kylheku <793-849-0957@kylheku.com> - 2020-08-13 00:43 +0000
Re: Supporting multiple input syntaxes Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2020-08-13 10:27 +0200
Re: Supporting multiple input syntaxes luser droog <mijoryx@yahoo.com.dmarc.email> - 2020-08-13 21:36 -0700
Re: Supporting multiple input syntaxes luser droog <mijoryx@yahoo.com.dmarc.email> - 2020-08-23 22:16 -0700
Re: Supporting multiple input syntaxes minforth@arcor.de - 2020-08-13 14:15 -0700
Re: Supporting multiple input syntaxes luser droog <mijoryx@yahoo.com.dmarc.email> - 2020-08-13 21:37 -0700
RE: Supporting mulitple input syntaxes Christopher F Clark <christopher.f.clark@compiler-resources.com> - 2020-08-14 12:44 +0300
Supporting multiple input syntaxes David Lovemore <davidlovemore@gmail.com> - 2020-08-15 06:42 -0700
Re: Supporting multiple input syntaxes luser droog <mijoryx@yahoo.com.dmarc.email> - 2020-08-15 15:20 -0700
Re: Supporting multiple input syntaxes David Lovemore <davidlovemore@gmail.com> - 2020-08-16 02:21 -0700
Re: Supporting multiple input syntaxes luser droog <mijoryx@yahoo.com.dmarc.email> - 2020-08-20 14:45 -0700
Re: Supporting multiple input syntaxes luser droog <mijoryx@yahoo.com.dmarc.email> - 2020-08-23 19:35 -0700
Re: implementation languages, was Supporting multiple input syntaxes luser droog <mijoryx@yahoo.com.dmarc.email> - 2020-08-23 20:39 -0700
Re: implementation languages, was Supporting multiple input syntaxes Thomas Koenig <tkoenig@netcologne.de> - 2020-08-24 17:01 +0000
Re: implementation languages, was Supporting multiple input syntaxes luser droog <mijoryx@yahoo.com.dmarc.email> - 2020-08-28 10:56 -0700
Re: stack languages, was Supporting multiple input syntaxes luser droog <mijoryx@yahoo.com.dmarc.email> - 2020-08-24 12:14 -0700
Re: Supporting multiple input syntaxes gah4 <gah4@u.washington.edu> - 2020-08-23 14:26 -0700
Re: Supporting multiple input syntaxes antispam@math.uni.wroc.pl - 2021-02-11 23:27 +0000
Re: Supporting multiple input syntaxes Elijah Stone <elronnd@elronnd.net> - 2021-02-17 01:44 -0800
Re: Supporting multiple input syntaxes antispam@math.uni.wroc.pl - 2021-02-23 23:28 +0000
Re: Supporting multiple input syntaxes "ltc...@gmail.com" <ltcmelo@gmail.com> - 2021-03-14 21:08 -0400
Re: Supporting multiple input syntaxes Rock Brentwood <rockbrentwood@gmail.com> - 2021-03-14 17:36 -0700
csiph-web