Embedding waxeye into other tools

[KOLANICH]

Currently this tool writes a parser into a file in the dir specified in CLI, and I cannot even choose the name for a file. But I wanna wrap this tool by another tool (UniGrammar). Could you, please, implement a mode making it write the parser into stdout?

[orlandohill]

Hi, thanks for suggesting this feature.

You can change the name of generated files at the command-line with the -p <prefix> option.

So far, I've avoided the assumption that a generated parser is contained within a single file. For example, the current Java backend produces two files. I could change things such that all generated files could be directed to STDOUT, but it might not be simple to generalize it to multiple files.

Do you have any examples of use cases other than UniGrammar?

[KOLANICH]

You can change the name of generated files at the command-line with the -p option.

It is still unsuitable. I mean it adds "_parser.py", so it cannot be used to redirect the output into an anonymous pipe (and creating a named one may mean writing to disk, which I try to avoid).

So far, I've avoided the assumption that a generated parser is contained within a single file. For example, the current Java backend produces two files.

It is possible to output several files and additional information into stdout by serializing it into CBOR (the format is binary and the strings are kept as they are, so no overhead of escaping). Or you can do even better by designing an own binary format.

[orlandohill]

I might support a more flexible naming system and generating to STDOUT in the future, but it seems like a low priority compared to other tasks.

I've thought about implementing the Language Server Protocol as a way to improve interoperability with other development tools. That's probably a few months away, at minimum.