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)

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