And yet I'm still too stupid to understand the macro system. Oh well.
I also didn't know there was a Chez version. Racket already has a native AOT compiler, right? What would the advantage be to run on Chez, faster or smaller compiled code?
I also didn't know there was a Chez version. Racket already has a native AOT compiler, right? What would the advantage be to run on Chez, faster or smaller compiled code?
If it's the former, I found this little article helpful when I was new to Scheme:
0. https://docs.racket-lang.org/syntax/Parsing_Syntax.html 1. https://www.greghendershott.com/fear-of-macros/ 2. https://summer-school.racket-lang.org/2018/plan/
#lang racket
(define-syntax-rule (run3times code ...)
(begin
(begin code ...)
(begin code ...)
(begin code ...)))
(define x 0)
(run3times
(set! x (add1 x))
(display x)) ; shows ==> 123
(In this case, it is better to use the build-in `for`. Actually, `for` is defined in a macro, it is not part of the internal "secret" low level language.)
Once you are confident and you grok the difference between a macro and a function, you can try the other ways to define macros. These other ways are more flexible and can make weirder macros, and have better support when the macro is used wrongly. There are good links in the sibling comments.
This talk[0] by Robby Findler helped me a ton when I was first learning about macros in Racket. I've found that the best way to learn, though, is by doing: when you find a use case for a macro, figure out how to do that particular thing and, slowly but surely, things will start to click.
As opposed to the larger group who think they understand them. I was once in that group, but now I've just given up.
defmacro was a lot easier, but I understand the aversion to it, even if it was rare that it was/is a problem.
[0] syntax-rules based macros are cake, naturally, but they're also incredibly limited, although I have seen people implement massive complex OO systems using a sort of ad-hoc state machine built in pages upon pages of syntax-rules rules.