Support for Clojure CLR

[brandoncorrea]

• Add deps-clr.edn
• Add reader conditionals for :cljr
• Add GitHub Workflow step for Clojure CLR tests
• Update README with placeholder for Clojure CLR installation
  • This will need to be updated once a new :git/tag / :git/sha is added

With this change, it may (or may not) be worth removing the ports section from README.md.

[brandoncorrea]

@weavejester The PR has been updated to include all your recommendations, except for those regarding test_runner.cljr and commit history. How would you like these addressed? Should commits just be squashed into a single "Add support for Clojure CLR" commit?

[tomdl89]

I'm assuming after this PR is merged, all future additions will need to consider CLR compatibility? The state of Clojure survey reports that about 1% of respondents use it (compared to about 99% Clojure and 65% Clojurescript), and a port does exist. Maybe a conversation instigated this which I've missed? But if not, I wonder if one is worth having? As a contributor with no interest in CLR, I worry this will dissuade me (and others) from contributing in the future. Why not update (and continue to maintain) the port?

[brandoncorrea]

I'm assuming after this PR is merged, all future additions will need to consider CLR compatibility? The state of Clojure survey reports that about 1% of respondents use it (compared to about 99% Clojure and 65% Clojurescript), and a port does exist. Maybe a conversation instigated this which I've missed? But if not, I wonder if one is worth having? As a contributor with no interest in CLR, I worry this will dissuade me (and others) from contributing in the future. Why not update (and continue to maintain) the port?

Great question. I considered updating the CLR port, but decided to go this route for several reasons:

1. The repo hasn't been touched in 2 years (probably due to the small number of CLR developers).
2. Forked repos will always be chasing changes to the root repo. Keeping them in the same repo allows us to reuse everything.
3. The dependency paths are different. If I have a CLR/CLJS project, for example, this forces me to have two separate dependencies, whether in a :cljr / :cljs alias, or in a separate deps.edn / deps-clr.edn. With everything in the same repo, I can share the dependencies with something like io.github.weavejester/medley {:git/tag "1.8.1" :git/sha "ef3a8ff"}.

While this does add a little extra work for contributors, the translations are quite simple. I believe the time I spent adding reader conditionals to the entire repository was maybe an hour or two. Scaling this down to only future changes, I imagine time spent thinking about cljr will be negligible, especially with many of these functions knowing nothing about the platform they run on.

I'm happy to move this PR over to the CLR port of medley, but I'll wait on @weavejester for that directive.

[tomdl89]

@brandoncorrea thanks for the answer. FWIW I'm not convinced the advantages you list outweigh the disadvantages (at least when weighted by number of those affected) but of course it's @weavejester 's call. Cheers

[brandoncorrea]

@tomdl89 Unofficial support of Clojure CLR may also be worth considering. This way, future contributors need not concern themselves with CLR. If there happens to be a release that doesn't fully support CLR and somebody wants those changes, they may contribute that those changes and see those in following releases.

[weavejester]

@tomdl89's observation is a good one, and certainly why I've rejected CLR ports in the past. However, there are a couple of differences in this case that make me more amenable to including this:

1. The GitHub action provides an easy way of checking compatibility.
2. It doesn't appear that many functions require much change.
3. It doesn't require many additional files, and it can be easily run under Linux/MacOS.
4. The pace of new functions being added to Medley has slowed down considerably.

New functions being added to Medley are rare enough these days that I don't think mind the overhead of helping getting them working with ClojureCLR, especially now I have ClojureCLR and cljr running on my Linux machine.

I'll give this a little more thought, but my inclination is that in this case it's a reasonable inclusion.

[E-A-Griffin]

Chiming in here as the maintainer of the Medley CLR port. I haven't updated it anytime recently but would be willing to or would be willing to accept PRs if there was desire for either, that being said, like @brandoncorrea I'd prefer to see the CLR port as a standard part of Medley.

As for @tomdl89's concerns, I think they're fair but a. CLR porting is usually easy to do (e.g. GUID instead of UUID type 1-to-1 changes) for these type of pure generic functions b. As @weavejester pointed out, Medley doesn't seem to be expanding rapidly in functionality c. ClojureCLR likely won't pick up interest for a number of folks until it's a fully fledged/easy to use language, part of which includes nice to have libraries like Medley, so I'd argue there's a bit of a "chicken and egg" issue here d. ClojureCLR is an official/standard Clojure platform/language (as opposed to something like Clojerl). David Miller for a long time has been the main ClojureCLR developer outside of the Arcadia project so having ClojureCLR libraries and projects he doesn't have to maintain or work on is helpful so the project does show it has community involvement/interest.