This is an early work in progress in pre-release of a LALR(1) parser generator. (as if the world doesn't have enough of them)
All it does so far is compute the nullable and FIRST sets.
More about what needs to be done is in TODO.
Development language is a bootstrappable sub-variant of Lox, as described in the book Crafting Interpreters by Bob Nystrom.
The sub-variant is equivilent to chapter 24 (Calls and Functions) from part III of the book with the addition of DOUBLE_QUOTE ('"'), pair(a, b), pair_first(p), and pair_second(p) in the runtime. This leaves out the language functionality in subsequent chapters providing closures and classes.
My effort to bootstrap that degree of functionality. (Up to chapter 23 in functionality)
For development I have been using a reference implementation at this degree of functionality using the original Nystrom code, which is useful for development purposes for its superior error handling and basic repl.
You could also use the completed (chapter 13) Nystrom reference implementation in Java if you added DOUBLE_QUOTE to the runtime and prepended the files object.lox and pair.lox as part of the runtime.
The goal here is to have a bootstrapapable means to generate a y.tab.c and y.tab.h from bash-2.0.5b/parse.y without relying on heirloom-tools yacc.
heirloom-tools Yacc has a free software license, the Common Development and Distribution License (CDDL) Version 1.0 .
This is not compatible with the free software license of M2libc, the GNU General Public License v3.0 (GPLv3).
That's not a problem if you're bootstrapping for your own purposes, as you don't need to distribute or retain the tools you used to bootstrap. (This is how the free world was built in the first place :] ). The final work product of a bootstrap like fosslinux/live-bootstrap no longer needs to retain a heirloom Yacc built in this manner.
But, it is a problem for GUIX where they like to keep copies of all built software in /gnu/store and where they want to ensure the end-users are in a position to be able to redistribute everything found there.
The original invocation of yacc or bison in the bash build is
$ yacc -d parse.y
where -d requests a y.tab.h file in addition to the y.tab.c
Because we have a simple I/O system for Lox (INPUT global var and print to standard out), the plan for getting seperate y.tab.h and y.tab.c output is to just run our deterministic parser generator twice on the same input with each file as a different output.
A primitive alternative to a module system is included, the project has seperate .lox files that are concatenated together with dependencies documented at the top as
// REQUIRE dep.lox
So you have to be careful what you do the the global namespace.
The not-easilly bootstrappable deps.py can identify the dependencies and generate a .d file for our Makefile.
The Makefile uses advanced features as well to ease development. Writing a bootstrappable kaem shell script as an alternative will come later and will be the easy part.