would it be a good idea to make % (or _) a placeholder in the threading macros?

[AlexKnauth]

For example, would something like this be a good idea to provide as an option?

#lang rackjure
(~> #"foobar" bytes-length (number->string % 16) string->bytes/utf-8)
;; or maybe this would be better:
(~> #"foobar" bytes-length (number->string _ 16) string->bytes/utf-8)

This would make ~> a lot more flexible, meaning the expression could go anywhere, not just in the 2nd position (for ~>) and last position (for ~>>). Also to me it seems weird to write (number->string 16) when it will really end up as (number->string (bytes-length #"foobar") 16).
But on the other hand it could interfere with #λ (if % was used) or match (if _ was used).

[greghendershott]

Maybe the "diamond wand" from swiss-arrows?

[AlexKnauth]

Yes that does exactly what I was thinking of.

[AlexKnauth]

I just made a topic branch and pushed what I have so far for my versions of the "diamond wand", but weird things are happening. https://github.com/AlexKnauth/rackjure/commit/142c62c9ae529c27f7900f56dc22392c5aca8a86 (~>_ 1 + (~>> 1 + _)) is producing (#%app (#%app +) '1 (#%app + '1)), (~>_ #"foobar" bytes-length (number->string _ 16) string->bytes/utf-8) is producing ((string->bytes/utf-8) (number->string ((bytes-length) #"foobar") 16)), and while I tried to make it so that it cooperated with #fn etc. using syntax properties, for some reason that's not working either.
Is the threading-syntax-parser helper automatically putting parentheses around the "form" before it passes the "form" into the "threader" function?
That would explain the first two. But is there anything I can do about it short of defining a new version of threading syntax-parser that wouldn't break the other threading macros?
And what does either check-expand-once or threading-syntax-parser do anything to get rid of syntax-properties before expanding? That doesn't make any sense, but if it did, that would explain the last one.

[AlexKnauth]

Ok I fixed it. https://github.com/AlexKnauth/rackjure/commit/6207041567c3b1b2a77e34b2ae536ba6c17c4a8f Defining a new version of threading-syntax-parser was a lot easier than I first thought.

[itegebo]

Alternatively, you could port the as-> macro.

[greghendershott]

Closing this as part of spring-cleaning. These days rackjure/threading simply re-provides the threading package, and that does implement using _ as the placeholder.