@chaosprint I'd love to take a shot at this, if you're not planning on doing it soon.

I also think this could be useful in implementing more robust docs, as all Node types could be in the same module and their doc comments could state how they should be used. (I also think it would be cool to make this documentation available in glicol-cli; not quite certain how that would work but I think it would be cool to have auto-generated information available inside glicol-cli about exactly what it supports)

Sure, feel free to take it on. For the cli, perhaps we can use https://github.com/mikaelmello/inquire in the future so that when users type glicol-cli in the terminal, they will be asked to choose between:

• watch a *.glicol file and start the audio engine
• show help of a node usage (maybe fetch from github)

So I'm still working on this (I've got the ast parsing in glicol_parser done, I'm trying to integrate it with the main crate now), and running into some issues with ergonomics. Specifically, I'm trying to make the parser zero-copy so that we can re-use the string allocations from the snippet of code we're parsing (and then just stick them together in a yoke::Yoke or something), but that makes it hard for someone to construct an AST manually, if they want to use glicol as a sound-creation library (instead of as a language-parsing library).

Do we want to make sure the AST can be easily programmatically created (i.e. make sure someone can create an AST without just parsing a snippet of code), or is that not a use-case we want this library to support? It wouldn't be too hard to support that (we could just make all the string borrows in the Ast enum be a Cow<'ast, str> instead of &'ast str so that someone could insert a Cow::Owned when they want to programmatically make an Ast, or make the main Ast enum generic over T: AsRef<str>, but both those add some complexity and unwanted side effects imo), but it seems to me that this library is mainly only intended to be used to process text, so I'm in favor of not really putting extra effort in to support other workflows.

What are your thoughts? (Also, did I explain this well? If you have questions, obviously feel free to ask)

So I'm still working on this (I've got the ast parsing in glicol_parser done, I'm trying to integrate it with the main crate now), and running into some issues with ergonomics. Specifically, I'm trying to make the parser zero-copy so that we can re-use the string allocations from the snippet of code we're parsing (and then just stick them together in a yoke::Yoke or something), but that makes it hard for someone to construct an AST manually, if they want to use glicol as a sound-creation library (instead of as a language-parsing library).

Do we want to make sure the AST can be easily programmatically created (i.e. make sure someone can create an AST without just parsing a snippet of code), or is that not a use-case we want this library to support? It wouldn't be too hard to support that (we could just make all the string borrows in the Ast enum be a Cow<'ast, str> instead of &'ast str so that someone could insert a Cow::Owned when they want to programmatically make an Ast, or make the main Ast enum generic over T: AsRef<str>, but both those add some complexity and unwanted side effects imo), but it seems to me that this library is mainly only intended to be used to process text, so I'm in favor of not really putting extra effort in to support other workflows.

What are your thoughts? (Also, did I explain this well? If you have questions, obviously feel free to ask)

Sorry for the late reply. I agree with you. There's no need to worry about making ASTs manually. If we're programming sounds instead of using Glicol syntax, we can just use what's in glicol_synth.

Can't wait to see the zero-copy stuff!