Konrad Hinsen wrote on 10/18/2017 03:53 AM:
I think what we’re really seeing here is that backwards compatibility
sometimes smothers elegant solutions. I firmly believe that in this
case we should simply throw out syntax-rules and syntax-case
A very good idea. At least throw it out from the tutorials and all
example code. Point people to syntax-parse right from the start. Keep
syntax-case to avoid breaking code, but don't advertise it any more.
I agree fully with continuing to support `syntax-rules` and
`syntax-case` in Racket (keep them working well, and keep them in the
reference manual), but teaching only `syntax-parse` in any
guides/tutorials/textbooks. Teaching the multiple forms with different
syntax just adds confusion and friction.
I'd just mention `syntax-rules` and `syntax-case` once in the document,
saying why they're not being taught, in case anyone wonders. And I'd
put notes in the reference manual bits about those two, encouraging
people to go to `syntax-parse` instead.
Suggestion: if you decide to teach only `syntax-parse`, you might want
to include using it without the help&burden of things like syntax
classes, not teach always using syntax classes. Otherwise, there would
be a lot of occasions when people can rapidly whip out a reasonable
`syntax-rules` example that looks a lot better than a full-features
`syntax-parse` one. I'm thinking that "idiomatic `syntax-parse`" should
also include "lightweight" uses of its features -- somewhat like how
people often prefer to use `racket/base` rather than Typed Racket.
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
