3 ms·
Why not keep the string as normal, but still do as you are suggesting? Shouldn't be too hard to have the macro parse it out so that the following would work, n
by taeric 1y ago
Why not keep the string as normal, but still do as you are suggesting? Shouldn't be too hard to have the macro parse it out so that the following would work, no?
(define-http-get-route ("/hello/:who")
(format #f "<p>hello ~a</p> " who))
- danlitt 1y agoIMO the whole point is to get rid of the string as normal. The whole "/hello/:who" syntax is weird and arbitrary, it is a different way of declaring a variable which adds an unnecessary extra step to understanding the code.
- taeric 1y agoIt matches the Open API specifications, is about the only reason I would try to support it.
- neilv 1y agoYes, with some of the fancier Scheme/Racket syntax transformers, you can do that string parsing at syntax expansion time. Sometimes it makes sense (e.g., if you want to support chunks of hairy SQL pasted into the code). I could go either way on how to specify Web server routes, but decided to go with the way I did, for 3 reasons: 1. Looks more familiar to Scheme programmers, without bindings coming out of strings (which I don't think is idiomatic Scheme). 2. Can be implemented more portably, including in Schemes that have only `syntax-rules` as a transformer. 3. If more semantics are added to the route specification later, such as type or validation, you might want want to be doing it in s-expressions rather than in a string.
- taeric 1y agoFair. I think my ultimate preference would probably be to have the string validated against the parameters. So, something like: (define-http-get-route ("/hello/:who" who) (format #f "<p>hello ~a</p> " who)) Prevents the confusion of people that remove a parameter from every path it was in, without also removing the parameter it would have bound to. Though, I suppose you would probably need to do a bit more to allow moving from query to path and such?