Heh, alright. syntax-parse it is.
Though I do wonder why the Guide/Reference don’t reflect this state of affairs.
It’s an additional library (you need to require it), whereas syntax-case and friends are in the core Racket.
But it would indeed be nice to have a pointer to the library.
Is there talk of including syntax-parse in Racket’s standard library?
There’s a discussion that it should be in Rhombus (previously known as Racket 2)
Is Rhombus still a thing? How serious is it?
Yes, it’s still a thing and definitely serious
Big things take time
Also, syntax-parse is in the standard library
Discussing it in the Guide would be a useful addition/change
@rmathews has joined the channel
In a thread yesterday, samth made a comment which sounded like he is saying syntax-rules should never be used.
Why is this? The <https://docs.racket-lang.org/reference/stx-patterns.html#%28form._%28%28lib._racket%2Fprivate%2Fstxcase-scheme..rkt%29._syntax-rules%29%29|reference documentation for >syntax-rules seems to indicate that it is just a small wrapper around syntax-case. From the conversation yesterday, it didn’t seem like anyone was saying to actively avoid syntax-case (just that syntax-parse was more feature-full).
@cdep.illabout_slack The message I got from yesterday’s conversation was that syntax-parse is what people actually use with Racket. There may be several reasons why the community doesn’t simply deprecate all other macro-writing utilities. I can think of the following: • syntax-case is (iirc) part of the Scheme standard, and while Racket is no longer considered synonymous with Scheme, I don’t think the core language developers want to abandon the standard just yet. • syntax-rules et al. are perceived by many experienced developers as easier for beginners (I don’t know if I completely agree here, but people do say this). At the same time, according to @greg’s Fear of Macros tutorial, syntax-rules and friends are almost deceptively easy, and don’t really give a good intuition for how macros work. In other words, it’s a double-edged sword when learning macros, but very simple to use. On the other hand, the syntax/parse library also includes provisions such as https://docs.racket-lang.org/syntax/Defining_Simple_Macros.html?q=define-simple-macro#%28form._%28%28lib._syntax%2Fparse%2Fdefine..rkt%29._define-simple-macro%29%29\|define-simple-macro, which work in much the same way, but also include all the goodness of syntax-parse under the hood. Thus my conclusion is that syntax-case and syntax-rules are included mostly for historical reasons, and aspiring macro writers should aim for syntax-parse.
I’m no expert in either, but my understanding is that syntax-parse does everything that syntax-case does, and a lot more besides, so there really is no good reason to eschew syntax-parse imo.
the tl;dr: • replace define-syntax-rule with define-simple-macro • replace syntax-rules with syntax-parse • replace syntax-case with syntax-parse
it’s not that the former are dangerous or bad or anything like that. it’s just that syntax-parse has all the same features and a lot more, and it gives you much better error messages by default even if you don’t use any of the extra features.
I’d say replace syntax-rules and syntax-case and with define-syntax-parser. For most applications you rarely need pure syntax-parse.
(In case it was not clear, define-syntax-parser is syntax-parse + define-syntax)
syntax-rules doesn’t cooperate well with disappeared-use properties, which make it less useful for me. syntax-parse and its wrappers have #:track-literals , which make things easier.