Ergonomics of macro implementation

[ModProg]

I see a few ways to improve ergonomics of macro implementation.

1. as (other than rust) we have first party Parse and ToTokens implementations the macro api could be Fn(impl Parse) -> impl ToTokens (though not sure what the implications would be for have a dyn Fn to store in the handlers Map. But this could also just be done by the rune::macro_ attribute, which would not actually change the handlers. (This is how I implemented https://docs.rs/manyhow/ for rust macros, though I only support the conversion between tokenstreams). If TokenStream implements both Parse and ToTokens than this would still allow the current usage. This would allow using it like so:

   #[rune::macro_]
   fn rename_fn(ctx: MacroContext, input: Parser, item: ast::ItemFn) -> Result<ItemFn> {
   fun.name = input.parse_all()?;
   Ok(fun)
   }

2. Some macros like anyhow, proc-macro-error or https://docs.rs/manyhow/latest/manyhow/macro.error_message.html could be neat. Maybe having a call_site concept for errors that will be replaced with the macro-span could be helpful for reducing needing to pass through the spans everywhere. But this might also just unnecessarily complicate things.

[udoprog]

I'm a bit skeptical in locking down a "higher-level" API. Any improvement could essentially be implemented as helper functions without having to commit to some specific signature. But I do welcome exploration into the space.

[ModProg]

yeah, this can definitely be seen as a future quality of live thing, and similarly to how manyhow is a standalone crate for the rust macro system, this could easily be implemented in a simple_rune_macros crate that exposes a macro for this.