CRAN release?

[krlmlr]

Are you planning a CRAN release of this package any time soon?

[dirkschumacher]

Do you have a specific usecase? I would not mind putting on CRAN

[HenrikBengtsson]

I think I've got plenty of use cases for what you've solved quite elegantly here. Some examples:

• optional run-time debugging (in the same spirit as debugme)
• optional run-time logging, possibly at different amounts (e.g. INFO, DEBUG, TRACE)
• optional run-time assertion, possibly partial or in full during checks (WISH: Near-zero overhead assertions r-lib/debugme#32)
• optional run-time profiling (e.g. enable timing and memory profile of futures for troubleshooting purposes)
• optional progress updates

... all with zero overhead when disabled (=removed on load). To me, as a developer trying to maximize correctness (=lots of assertions) and performance (=minimal number of asserts), being able to use macros that can be enabled and disabled when the package is loaded is of great value. Another benefit is that the code that print(<function>) outputs and that is used/seen when debugging is cleaner when above "non-essential" code is disabled/removed.

[HenrikBengtsson]

One wish, though, for a CRAN release, please minimize package dependencies to make this package as lightweight as ever possible.

Specifically, I think the only use for rlang is in:

defmacro/R/macro.R

Line 72 in feac559

result <- exec(fun, !!!as.list(ast)[-1])

I haven't tried, but that can probably be replaced by a do.call(fun, args = ...) call.

[dirkschumacher]

I am open to doing that since there is obvious demand (at least 2 people :)). I agree that it would be good to have minimal dependencies to make the package as robust and maintainable as possible.

A quick list of things that need to get done for a first version:

• Replace CI with Github Actions
• Investigate removing rlang from Imports
• Bonus: Replace the current imperative tree walker with a recursive one. This might cause problems with extremely deeply nested code, but comes with the advantage of easier maintenance and understanding for new contributors. Also, compiler is recursive, so I guess it should be fine.
• Improve documentation (e.g. document usage #6)
• Test the package in a real package :)
• Maybe also document limitations. E.g. I could see problems when macros depend on the prior execution of other macros. This could be solved e.g. by restarting the expand onLoad function whenever a function is expanded.

Anything else?

[dirkschumacher]

@krlmlr you added rlang, which made the code obviously more readable. Did it also solve any other issues?

[dirkschumacher]

@HenrikBengtsson before I publish it on CRAN, it would be great if you could test the package in one of your packages to see if it really works.

[krlmlr]

I don't mind removing rlang if it causes strong feelings.

Also, I'm ready to tick the "Test the package in a real package :)" bullet. Specifically, I'd like to explore usage of this package for expanding DBItest tests: r-dbi/DBItest#267. The linked PR exports way too many functions from DBItest. If those were macros, the tests would become larger, but also easier to troubleshoot in case of failures.

If a CRAN release in the near future is elusive, adding the package to r-universe would be great too: https://dirkschumacher.r-universe.dev/ui#packages.

[dirkschumacher]

I don't mind removing rlang if it causes strong feelings.

It's already gone from the dependencies.

Also, I'm ready to tick the "Test the package in a real package :)" bullet.

Let's do it then. Only thing left is polishing the DESCRIPTION file I believe.

[dirkschumacher]

BTW. @HenrikBengtsson @krlmlr you both contributed to the package. Happy to add you to the DESCRIPTION file. Or better, make a PR :)

[krlmlr]

Thanks. I wonder why this package doesn't show up in your R universe. Do you need to set up manually?

[krlmlr]

I'll try to start using defmacro in DBItest in the next few days. I need to confirm that it actually solves my use case.

[dirkschumacher]

Sure go for it. Or do you need it on cran first?

[krlmlr]

No, rather the opposite -- I'd take the opportunity to provide feedback, if necessary, before it hits CRAN.

[krlmlr]

It wouldn't hurt if it were on R-universe, though.