LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jonathan Spratte <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Wed, 19 Feb 2020 15:06:15 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (27 lines)
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.

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

ATOM RSS1 RSS2