Whoops, I replied with the wrong button the first time around. See previous message.
1 Like
It was about 18 months ago now, I forget a bit... looking back it seems I ran into it with sql and not db (I ended up switching to using db instead)
The example that bugged me at the time was create-table (docs SQL: A Structured Notation for SQL Statements)
For some reason this isn't a function taking a string arg for the table name, but a macro that uses a ... syntax token (? 
)
e.g. in this example
(create-table numbers
#:columns [n integer #:not-null] [t text]
#:constraints (primary-key n))
... numbers isn't a variable but the actual name of the table to create.
To be fair, the docs linked above highlight this as a "syntax" rather than a "procedure".
Then the other confusion I had was racket - Dynamically generating rackunit test-suite: tests pass and also raise exception - Stack Overflow ...again this was my fault for trying to treat a syntax as a function, and I eventually found a pleasant solution.
My feeling at the time was that syntax macros make things easier for library authors at expense of making creative usages more cumbersome for users. But I think that's not fair or true, and the "problem" was more of an impedance mismatch between my Python-trained brain and the Racket ways of doing things.
I think naively trying to avoid syntax macros was a mistake on my part, and I think maybe they should be among the first things you learn to manipulate and create - at least for those coming to Racket from other langs and not totally new to programming.
Probably there are useful lessons to learn from the decisions made in these Racket libraries, to understand why test-case is a syntax macro and not just a function that returns a test case. Probably there are common techniques and design patterns involved, maybe solving familiar problems but in a non OOP way.
Anyway, all this is just first impressions of a newcomer.
2 Likes
Thanks, that makes sense.