I’d guess not much

I am pretty sure that clojure.data/diff use doesn't require sets back now, but would work ok if it got sets back instead of a sequence like it does now.

There is a patch for a JIRA ticket I wrote that changes clojure.data/diff to coerce the args it sends to clojure.set functions to sets inside of clojure.data/diff code, and it passes all tests, but don't recall if the code path is exercised in existing automated sets, so that may not mean much.

Also see https://github.com/slipset/speculative/issues/46#issuecomment-435568789

@alexmiller here’s another example for the 1.10 error handling improvements (tested on 1.10-beta4) 🙂

user=> (let [{keys [a b]} {}])
Syntax error compiling at (1:1).
Unable to resolve symbol: a in this context
user=> (let [{:keys [a b]} {}])
nil

Some more changes coming shortly with CLJ-2420... won’t change this much though

Are instance? checks as good as free? If not, it might make sense to only coerce certain places of set functions to ensure the output is a set, e.g. the first set that goes into the final reduce

They’re not free but they are pretty optimized in the jvm

a lot of set functions first do a count on the inputs, to decide what set to start with. I guess if the input aren’t sets, it may make sense to have them coerced before you do that… or not… worth a perf test 😉

>alexmiller [10:04 PM] >also, you might notice that symbol can now take a var or a keyword … and tehre was much rejoicing >

user=> (symbol #'+)
>clojure.core/+

can you start with a problem and describe the proposal? I don’t have time to read all that and infer it.

generalizing the rejoincing of (symbol #'+), extending it to keyword & name, and adding support for namespaces.

Benefice: I don't have to delve into the java interfaces and remember when to use the .sym, .ns, .getName .toSymbol, etc.. methods

@tristefigure In eight years of writing production Clojure I don't recall ever needing to call any of those Java methods on things. What sort of code are you writing where you run into that level of interop because you can't just use "plain ol' Clojure" functions?

I guess we could turn it around and ask @alexmiller what problem was solved by making those changes?

Comes up all the time when doing a lot of macrology, var to symbol is particularly common - it’s all over spec and core in various places and there has never been a convenient way to do this, other than diving into Java fields

I’m still not clear what problems you’re trying to solve above or what changes are being proposed

It's just to enhance homogeneity and symmetry of these functions. They should apply to anything that can either be used as a name (strings, keywords, symbols) or deemed as having a name (vars, namespaces). The changes: https://gist.github.com/TristeFigure/0e6e9f7834339288425c6dd62d368635#file-explore_round_trips-clj-L170 https://gist.github.com/TristeFigure/0e6e9f7834339288425c6dd62d368635#file-explore_round_trips-clj-L186 https://gist.github.com/TristeFigure/0e6e9f7834339288425c6dd62d368635#file-explore_round_trips-clj-L205 (i can also provide a patch for this if someone can provide me the canonical git expression to do so).

"It's just to enhance homogeneity and symmetry of these functions." -- but that's not an actual problem in and of itself.

It is very common to think of the situation "I don't want to have to remember the asymmetric restrictions when converting between this collection of types" as a problem that seems easily solvable via removing those restrictions. In the end, is it reasonable to say that what is a problem, and what isn't, addressed via Clojure core is a judgement call, and part of what we almost always love about Clojure are the judgement calls of the core team?

(except when we disagree with the judgement calls, in which case we easily get a bee in our bonnet that lasts for years) ("we" meaning me, really -- not pointing fingers at others here)

FYI, instructions for creating patches in the form expected for Clojure JIRA tickets are on this page (search for 'format-patch', but the instructions shortly before that are relevant, too): https://dev.clojure.org/display/community/Developing+Patches

Here is an interesting github search that tries to locate conversions from Namespace to Symbol/String (half of it is noise though) https://github.com/search?utf8=%E2%9C%93&q=ns+getName+language%3AClojure&type=Code Looking at it, it seems Class -> Symbol/String is also often used.

You are welcome to create a JIRA ticket describing what you see as the problem, and even proposed solutions and/or a patch. The following is a mantra I need to repeat to myself more often: What I want isn't necessarily what the owner of Clojure wants, and owners get to choose.