4:24:13aethDoes anyone else use a macro as the way to access things to avoid potentially dozens of exports in a package? What I've been doing is a with-foo-accessors that places the accessor symbols in the package specified at the definition of that macro and also can add a prefix (for the case of structs with conc-name not set to nil).
4:25:03aethI find that this greatly simplifies things because then I only need to export the with-foo-accessors macro and/or a macro that indirectly uses that macro.
4:26:59aethe.g. (with-foo-accessors ((foo foo)) foobar ...) would macroexpand to (with-accessors ((foo the-package-containing-foobar::foobar-foo)) foobar ...) in the most complicated case (where it's a struct with prefixed accessors)
4:40:31pilltonaeth: Yes, but not to avoid the number of symbols that are exported.
4:44:08aethMy macro, in case anyone's curious: https://gitlab.com/zombie-raptor/zombie-raptor/blob/ec47910d88254d0c6a0e8c0a33aa33c7d4037513/util/util.lisp#L247-260
4:44:36aethdestructuring-lambda is just a lambda that does a destructuring bind on its one argument. It's surprisingly common. In fact, I just now noticed the pattern in define-accessor-macro
5:02:31lokeaeth: What's with the INTERN calls in the macro?
5:09:42aethloke: Otherwise the macro will produce something whose API is (zombie-raptor/util/util::foo)
5:28:01lokeaeth: instead of your reader macro dance, just use (intern "FOO" env)
5:33:15aethloke: I use #.(symbol-name ...) pretty much everywhere instead of hardcoding the symbol as a string of upper case characters
5:38:49aethI know it's essentially pointless, but at least to me it feels better to not hardcode the assumption about the reader that will almost certainly be valid. Perhaps this could be turned into something more concise?
5:42:31aethBut... I suppose I should be using &environment env instead of assuming intern without that argument would work correctly