Hi Birdt,
Welcome to the Chicken community!
I have briefly looked over the code, and I it looks well-written to me. You're using implicit-renaming and gensyms which should avoid the most common pitfalls. In my opinion, your use of unquoted splicing makes it all very readable.
You could use handle-exceptions [0] to test it if you use error or raise instead of assert. These are part of chicken itself and as such requires no external dependencies.
As puplishing this as an egg, however, and in danger of being discouraging, I wonder how general this macro is. For example, variables are always placed as the first argument:
... (x (even?) (> 5)) ...
=> (and (even? x) (> x 5)) ...
Things like this may be considered un-Schemeish by some. There are many existing helpers that let you address arument-placement like this. For example: flip, compose, cut/cute, case-lambda, -> and ->> and many more. In the regime above, it may be hard to take advantage of these. Writing a useful, reusable and expressive macro is truly an art.
I don't know if it's relevant for your use-case, but Chicken allow you to declare types [1]. These are sometimes are able to detect errors at compile time.
When I first started writing Scheme, I wrote a macro for everything. One for looping, one for starting threads, and one for including the git tag at compile-time and so on. But I learned that custom macros make code harder to read in the long run because you can't jump into a section and understand it. You first need to review it's macros. That cost is bigger than the benefit of a slightly shorter program.
This is just my opinion, and I hope this isn't discouraging. Keep writing macros and post them here! We appreciate your input.
K.
[1]:
http://wiki.call-cc.org/man/5/Types
Hi all!
I'm not very experienced with Scheme or Chicken, but I've written a small macro which I've found useless on a few learning projects which I thought I'd share with the hope of getting it included on the package list.
The repo is
here (along with a release-info, provided I understand the format correctly), I'd appreciate any feedback on the macro itself as I'm sure it's written in a very inefficient way (I'm not even sure if using `assert` is best here, instead of a conditional `error`) and I'd like to improve it since I like using this syntax.
Also, is there a way to capture assertion failures at runtime? I've neglected to write any unit tests at present since I'd like to do this without any third party libraries simply for the learning experience.
Thanks and o7,
Jakub