I haven’t used it, so take my feedback with a grain of salt.
I find that the API semantics were designed very tastefully.
I’d think twice before introducing it in my team: as all those libs which are their own DSL (like Specter), you have to ponder the tradeoff between expressiveness and accessibility.
I’m not very comfortable with the interpretation of symbols syntax (the ! prefix etc.). I like relying on the invariant that symbols are ‘atomic’ (and I guess my tooling likes it even more than I do). Maybe this sort of annotation should go to symbol metadata, or to the namespace part of the symbol (destructuring provides an official precedent for that).
Thank you for your feedback, I really appreciate it.
I think I understand what you mean by “libs which are their own DSL”. But in the meantime, I do not really think of it as a DSL, since it is not domain specific but general purpose and maybe more importantly it does not bring a whole bunch of ideas and elements into the host language (as Specter does). The thing that is the most DSL-ish is the prefixed symbols I believe.
After reading your comment last night, I tried to remove them and strip the idea to its minimal form. I share your concerns about tooling and ‘atomicity’ of symbols. And I think that if the whole code fit in a page it should really increase accessibility.
There is an error in your Readme. In boolean connectors, (= true "..." (and true nil)) is false. Sorry I don’t know how to comment on your Readme in situ.