Hi, I'm trying to use λ~> with applicable dictionaries and I'm running into an issue where Racket complains 'x is not a procedure:

#lang rackjure

(define h (hasheq 'x (hasheq 'y 1)))

; works
(~> h 'x 'y)

; works
((λ (v) (~> v 'x 'y)) h)

; fails: expected a procedure that can be applied to arguments, given: 'x
((λ~> 'x 'y) h) 

Am I doing something wrong? Looks like somehow Rackjure doesn't kick in when running the last example.

Could you please change the version number to, say, "1.1"?

As I'd mentioned in another issue, I need you to bump the version number, anyway, so that I can depend on user pulling something with commit efa04c or newer.

And also, "1.0.0" is not a valid-version? for the package manager. Although you can have a trailing 0 in the minor place, you can't in the build place:

#lang racket
(require version/utils)
(valid-version? "1.0")   ;#t
(valid-version? "1.0.0") ;#f
(valid-version? "1.0.1") ;#t

And indeed "1.0.0" is causing a problem:

https://travis-ci.org/greghendershott/rackjure/jobs/85218799#L146

$ raco pkg install --deps search-auto --link rackjure
Resolving "threading" via http://download.racket-lang.org/releases/6.2/catalog/
Resolving "threading" via http://pkgs.racket-lang.org
Downloading https://github.com/lexi-lambda/threading/tarball/efa04caf4f792381018b2cf07b1dc72f022ace7a
pkg: bad verson specification for threading: "1.0.0"
raco pkg install: version mismatch for dependency
  for package: rackjure
  mismatch packages:
   threading (have 0.0, need 1.0)

The command "raco pkg install --deps search-auto --link rackjure" exited with 1.

All Racket packages I've seen so far stick with major.minor versions. You don't have to, of course. But if you do use a release number you'll need to be careful that it's never 0.

The master branch depends on 6.2, so the branch for 6.1 and below should be used as the version exception for 6.1.1 as well.

Add <~ for threading in other direction.

So instead of (~> {n - 1} fact (* n)) one could write (<~ (* n) fact {n - 1}).

Travis ran a "cron" job today on frog and it failed for Racket 6.2:

Downloading https://github.com/lexi-lambda/threading/tarball/dee85e8d3cffaed85eb27bed8a8c61fc1eea8395
raco pkg install: version mismatch for dependency
  for package: rackjure
  mismatch packages:
   threading (have 0.0, need 1.1)
make: *** [install] Error 1

It looks like this is due to your recent commit de68f80 ?

Interestingly frog built fine for Racket 6.1 and 6.1.1 -- is that because you have a version exception? It looks like 6.2 is falling between these two approaches?

Note that Pollen uses markdown which uses rackjure which uses threading, so, I'm kind of caught in the middle here. On April 11 I dropped support some older Rackets but @mbutterick said Pollen needs to support 6.0 so I undid that on April 12.

[Split out as requested from #1]

Rackjure's threading macros have special cases so that (~> v 's) -- which is really (~> v (quote s)) -- expands to ((quote s) v) not (quote v s). The latter obviously isn't useful, but why is the former? Because rackjure's #%app treats the application of a symbol to a dictionary (and vice versa) as a dict-ref.

This simply requires an extra syntax-parse clause such as:

 [(_ v ((~literal quote) e:expr)) #'((quote e) v)]

Is this likely to be needed by anything other than rackjure? I don't know. Maybe not. But I'd argue that it's harmless, as (quote x y) is a syntax error, so removing the ability of ~> to expand to such a syntax error is not a bad thing.

Even if this seems like a silly quirk? If it is still a goal for this to be the one threading macro package that existing as well as future Racket packages share, then there probably needs to be some reasonable accommodation for non-harmful quirks like this?

[Split out as requested from #1]

Doing so ensures that Racket's macro expander will use the #%app in that lexical context.

This is discussed in rackjure issue 25. However it is not really unique to rackjure. Racket allows #%app to be redefined. Threading macros are about an alternative syntax for application. They should use the notion of application in effect at the site of the macro invocation.

The clojure library swiss arrows provides a nice function threading operator that would probably be translated to ~<>:

The Diamond Wand - similar to -> or ->> except that the flow of execution is passed through specified <> positions in each of the forms.

(-<> 2
     (* <> 5)
     (vector 1 2 <> 3 4))
 => [1 2 10 3 4] 

It's nice and useful and it would be nice to have I think.

[Split out as requested from #1]

This is discussed in rackjure issue 28.

http://dev.clojure.org/jira/browse/CLJ-1121

[Split out as requested from #1]

This would make it easer for rackjure, which currently supports Racket 5.3.2 or newer, to use this package.

In my experience with rackjure's threading.rkt, nothing requires any special treatment for Rackets as old as 5.3.2. It is straightforward to add builds to the .travis.yml and verify that the tests pass.

I'm not suggesting making any non-trivial effort to support older Rackets. And if at some point it were to become awkward to support an older Racket, I think it would be totally reasonable to drop support. Meanwhile, I'm suggesting just "assume compatible until demonstrated otherwise".

First, thanks again for taking the initiative to have one, go-to threading package.

I mentioned a few ways in which rackjure's threading macros had evolved, that you might want to consider, and that rackjure would need in order to drop its own module and use your package instead.

I thought it would be easiest to present/consider them all together, at least initially. However if you'd prefer me to open each as its own issue, I'd be happy to do that.

1. Don't thread into quote forms

Rackjure's threading macros have special cases so that (~> v 's) -- which is really (~> v (quote s)) -- expands to ((quote s) v) not (quote v s). The latter obviously isn't useful, but why is the former? Because rackjure's #%app supports applying a symbol to dictionary, to be a dict-ref.

This simply requires an extra syntax parse clause such as:

     [(_ v ((~literal quote) e:expr)) #'((quote e) v)]

However, the template will become a little more complicated than that after addressing the remaining issues.

2. Use the lexical context of the ~> syntax

Doing so ensures that Racket's macro expander will use the #%app in that lexical context.

This is discussed in rackjure issue 25. The issue references two commits, because it took me two attempts to get it right :) and I was less compulsive back then about squashing commits before pushing :).

3. Avoid CLJ-1121

This is discussed in rackjure issue 28.

The commit fixing this also involved some pretty substantial refactoring of the code by @qerub. Because of that, and because CLJ-1121 is arguably a corner case, I'm not sure how enthusiastic you'll be about this, but I wanted to point it out.

4. Support Racket 5.3.2

You might be least enthusiastic about this. On the one hand, it's probably easier than you think, and I'd rather not drop an old Racket version for rackjure unless necessary. On the other hand, I only knew one person using it on a version that old, and that was probably 2 years ago, so maybe I could change this.

When you have time, please let me know what you think about these? Also, do you have any preferences about trying to incorporate these changes yourself, vs. me giving you pull request(s)?

Thanks again!

At the moment, you seem to have -> to insert the result as the first argument, and ->> as the last.

What if I wanted a variant that would put it in the second argument, or even a variant that used the result to call the next function?

How hard would it be to have a variant that let users specify where they would like the result to go?

rackjure provides some~> like Clojure's some->. Ditto for >> flavor. I'll need to continue to provide those.

AFAICT this is the same as your and~> and and~>>?

1. I'd welcome another set of eyeballs in case I'm missing a difference.
2. Assuming they're the same, I could re-provide and~>{>} with an alias some~>{>}, in rackjure. Unless you wanted to do so here. (Either is fine with me; I'm happy to do it in rackjure. Just wanted to ask first. Because if you were to add it, later, it would break rackjure unless I required you only-in. But I'd prefer not to use only-in, I'd prefer that rackjure is just a simple reprovide of whatever you might add in the future.)

(I see no such declarations in the repo.)