## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Classic View Use Monospaced Font Show Text Part by Default Condense Mail Headers Topic: [<< First] [< Prev] [Next >] [Last >>]

 Sender: Mailing list for the LaTeX3 project <[log in to unmask]> Date: Thu, 20 Feb 2020 11:00:47 +1300 Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]> Message-ID: <[log in to unmask]> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit In-Reply-To: <20200219140615.GH10540@thinkarch> Content-Type: text/plain; charset=utf-8 From: Henri Menke <[log in to unmask]> Parts/Attachments: text/plain (54 lines) On 2/20/20 3:06 AM, Jonathan Spratte wrote: > I have *no* idea about parsers. I just rewrote the letter-by-letter parser > of PGF because I felt a few options missing (and the implementation is > nowhere near as powerful as it could be) when I heard about it and wanted > to play with it. I don't have any serious application for it, in PGF it is > only used for the SVG parser of the svg.path library. > > But I toyed with the idea to write a standalone package which includes a > similar letter-by-letter parser (well, actually it's a token-by-token > parser), just so interested users don't have to load the rather hefty > overhead of PGF. Just for the record, you don't have to load the full PGF to be able to use the parser module. Maybe I should make a package for that. \documentclass{article} \usepackage{pgfkeys} \usepackage{pgfrcs} \makeatletter \let\pgfset\pgfkeys % should use \pgfqkeys in pgfmoduleparser.code.tex \input{pgfmoduleparser.code.tex} \makeatother \begin{document} \newcount\mycount \pgfparserdef{myparser}{initial}{the letter a}% {\advance\mycount by 1\relax}% \pgfparserdef{myparser}{initial}{the letter b}% {} % do nothing \pgfparserdef{myparser}{initial}{the letter c}% {\pgfparserswitch{final}}% done! \pgfparserparse{myparser}aabaabababbbbbabaabcccc There are \the\mycount\ a's. \end{document} > Best, > Jonathan > > On Wed, 2020-02-19 12:27:31, Bruno Le Floch wrote: >> I've been *toying* for a long time (haven't gone very far) with the idea >> of writing a parser generator, but I couldn't decide how powerful to >> make it. One option would be to support "parsing expression grammars" >> (PEGs), which can be parsed in linear time using a packrat parser (but >> use a lot of memory, possibly problematic). Another option would be to >> stick with more traditional things like LL or LR parser. To be honest, >> I don't know enough about parsers and what useful languages they cover >> to decide. Thoughts welcome. >> >> Best, >> Bruno