Open DanielFlaum opened 2 years ago
This is an interesting idea. I agree that a simple C-style approach would be easiest, these files really shouldn't grow to be that large. However Its not quite as trivial as it may seem, I'm specifically concerned about handling the header component where people can specify any imports or type declarations etc. to be included at the top of the file, these would need to be handled with some care, but it sounds quite feasible.
Perhaps a simple change towards properly supporting grammar splitting is to allow the cli to accept multiple grammar files interpreted as a concatenation of the contents of each?
Large grammars can be difficult to manage in a single file. Being able to split grammars among multiple files would increase the feasible scale of applications, such as by enabling the separation of lexing rules from paring rules.
The simplest implementation would probably just prepend the contents of other files, as in the C preprocessor. It would be more helpful if grammars could indicate that they are modular or standalone, and could indicate whether symbols are public/exported for use by other grammars or private/unexported for internal use only.