Placeholders in chain-* macros?
John Cowan
(23 Aug 2020 20:42 UTC)
|
Re: Placeholders in chain-* macros?
Marc Nieper-Wißkirchen
(23 Aug 2020 21:12 UTC)
|
Re: Placeholders in chain-* macros?
Marc Nieper-Wißkirchen
(23 Aug 2020 21:13 UTC)
|
Re: Placeholders in chain-* macros?
John Cowan
(23 Aug 2020 21:15 UTC)
|
Re: Placeholders in chain-* macros?
Marc Nieper-Wißkirchen
(23 Aug 2020 21:42 UTC)
|
Re: Placeholders in chain-* macros?
Adam Nelson
(28 Aug 2020 02:32 UTC)
|
Re: Placeholders in chain-* macros?
Marc Nieper-Wißkirchen
(28 Aug 2020 05:33 UTC)
|
Re: Placeholders in chain-* macros?
Adam Nelson
(31 Aug 2020 17:01 UTC)
|
Re: Placeholders in chain-* macros?
Marc Nieper-Wißkirchen
(31 Aug 2020 17:28 UTC)
|
Re: Placeholders in chain-* macros?
Marc Nieper-Wißkirchen
(02 Sep 2020 07:26 UTC)
|
Re: Placeholders in chain-* macros?
Adam Nelson
(06 Sep 2020 16:54 UTC)
|
Re: Placeholders in chain-* macros? Marc Nieper-Wißkirchen (06 Sep 2020 17:14 UTC)
|
Am So., 6. Sept. 2020 um 18:54 Uhr schrieb Adam Nelson <xxxxxx@nels.onl>: > I don't think a warning is necessary; there's nothing about the way > chain uses keywords that is any different from the way any other macro > uses keywords, so this is a universal hygiene issue in Scheme. And SQL > injection isn't a fair comparison. You should never be passing > user-provided data into the macro expander at runtime; if you're doing > that, you have bigger problems. The SQL comparison was indeed a bit pointed. And yes, other special forms have a similar issue, for example, the cond form, which uses the keyword "else" in place of an expression. If you think the danger of identifier collision with the chain macro is not greater than with the cond keyword, maybe it is not worth to do all the necessary changes for a custom placeholder. I'm not sure. In my chain-using-macro example, one can always replace `temp` with `(values temp)`. Interestingly, an alternate version of chain that would bind `_` unhygienically (to identifier syntax) wouldn't suffer from this hygiene issue. > I appreciate all of the feedback on this SRFI, and it's really helped me > refine it into something more sophisticated than a simple port of a > Clojure feature, but it's reaching a point that I can't keep making > changes and debating them and dragging this out. When I make this change > I intend for this to be the final version of SRFI 197. I don't want to > add or remove any more features; I have a lot of other projects going > on, and even other SRFI ideas, and this SRFI process has taken much > longer than I expected it to. I will submit the next version as draft 5 > for proofreading, but I intend to move it to final within a few days. That's understandable. Anyone who seeks more extensions to the macros can always create a new SRFI building upon and extending SRFI 197. Or write a SRFI for a chain and nest with alternate semantics (like deep binding). Thanks for all your endurance! Marc