Consider alternatives to SLY long term for backend parser

[MicahGale]

We have always known that SLY was no longer supported. Frustrations with finickiness and other issues has made me scared for the possibility that one day SLY just doesn't work.

I started this mostly to start collecting information on viable alternatives.

• Pyparsing Last update Mar, 2024
• Parsley last update: 2015

If we are rewriting everything it is probably worthwhile to go to a compiled language base and speed up a lot, so:

• Lexx, Yacc
• pest.rs

keywords: parser, backend, SLY, compiled parser

[MicahGale]

Another option that came up was lexxy

[MicahGale]

Library for rust bindings and wheel generation: https://www.maturin.rs/

[MicahGale]

So as part of these we would have to decide which platforms are and are not supported. https://peps.python.org/pep-0011/. Should we just say we only support tier one platforms? Or should we go deeper?

[MicahGale]

I finally looked closely at the Pest graph on it's homepage, and discovered that Pest is not the fastest parser in the west. Their competitor, nom, https://web.archive.org/web/20250129191011/https://unhandledexpression.com/general/2018/10/04/no-pest-is-not-faster-than-nom.html, takes that title (probably) in the rust landscape while still being generalizable. (The fastest tool is a json specific library).

nom uses parser combinators. I'm a bit hesitant, because this seems less legible than sly, so further research is needed.

[MicahGale]

I just ran a benchmark to see if sly is actually that slow in this application. I got:

Read 9.88 MB in 179.42 s at 55.07 kB/s

For context Pest is 4 orders of magnitude faster at 150 MB/s. Though this does still have the overhead of everything else in montepy.

This ran from:

Details

In [1]: import os

In [2]: import io

In [3]: import time

In [4]: import montepy

In [5]: cd ~/schoolOneDrive/
/home/mgale/schoolOneDrive

In [6]: file_size = os.path.getsize("faux_iter_c.imcnp")

In [8]: with open("faux_iter_c.imcnp", "r") as fh:
   ...:     contents = fh.read()
   ...:     str_fh = io.StringIO(contents)
   ...:     str_fh.seek(0)
   ...:     start = time.time()
   ...:     _ = montepy.read_input(str_fh)
   ...:     end = time.time()
   ...: 

In [9]: time = end - start

In [13]: print(f"Read {file_size / 1e6:.2f} MB in {time:.2f} s at {file_size / time / 1e3:.2f} kB/s")
Read 9.88 MB in 179.42 s at 55.07 kB/s

[MicahGale]

Today I was reviewing a lot of MCNP input types (#853), and I realized that almost all data inputs are regular grammars, as well as surfaces are regular. So far it only seems that Cell has a context-free grammar which is not regular. So one option is to go hard with regular expressions. I'm not sure how fast it would be, and it would require a lot of infrastructure to make a DRY grammar, possibly our own RE engine, but that is an option for every grammar but Cell.