Fork me on GitHub
#clojure-dev
<
2016-06-14
>
alexmiller20:06:31

put it on the ticket

ghadi20:06:11

will do -- I have a dirty fix to VarExpr in the compiler, but a better fix is like bronsa says to remove the :tag typehints in core and adjust the arglists hints

dajjedzenie20:06:14

if it's a type hint thing and all that's needed is to change the wrong ones I could do that (if no one wants to, that's it); if it's fancier I'd need a hint where to look at

alexmiller20:06:51

@ghadi: it seems like generally it shouldn't be possible to break the ability to call .hashCode()

alexmiller20:06:03

however, I'd say this is not at all high on my list of things to care about

ghadi20:06:57

it's not just hashcode tho šŸ˜ƒ

dajjedzenie20:06:37

or would hijacking the old ones in fn work better?

ghadi20:06:20

here's another example @alexmiller :

user=> (set! *warn-on-reflection* true)
true
user=> (.submit clojure.lang.Agent/soloExecutor str)
Reflection warning, elided.clj:1:1 - call to method submit on java.util.concurrent.ExecutorService can't be resolved (argument types: java.lang.String).
#object[java.util.concurrent.FutureTask 0x4b10966e "[email protected]"]

ghadi20:06:49

that reflects because the compiler things str is a String and not a callable

ghadi20:06:34

actually it would reflect anyways because it doesn't know that a fn var deref is Callable -- but you see the gist of the type inference problem

ghadi20:06:34

I could probably think of a more problematic example.

ghadi20:06:17

like choosing the wrong method when java arguments are type overloaded

alexmiller20:06:50

so the .hashcode thing is uninteresting except as a symptom. If you want to improve one of those tickets, maybe the older one is better, that's where I would start.

alexmiller20:06:31

why did you say it would be better to adjust the :tag / typehints? seems like that's hiding the problem, unless you're saying that the code is actually wrong.

bronsa21:06:24

@alexmiller: yes that'd be indeed hiding the problem, but the problem is not solvable w/o breaking existing semantics

alexmiller21:06:57

well then maybe we shouldn't solve it :)

alexmiller21:06:37

mostly trolling :)

ghadi21:06:44

maybe we shouldn't šŸ˜ƒ

ghadi21:06:57

people forget that's a defensible position

bronsa21:06:43

well, ret value type hints on a defn Var have been unofficialy deprecated for a while.. I wouldn't mind replacing all those instances in clojure.core with type hints on the argvec and printing a deprecation warning on old instances of type hints

alexmiller21:06:44

I'd be fine with having a ticket like that (but without the patch on core as that is not worth maintaining) for Rich to look at

alexmiller21:06:13

@dajjedzenie: sorry for ignoring you earlier, was trying to understand the problem

dajjedzenie21:06:57

got it, np šŸ™‚

cfleming23:06:04

Why have the var type hints been deprecated?

cfleming23:06:44

Iā€™m still doing that to avoid having to use fully qualified type hints on the arg vec, although IIRC that might have been fixed in 1.8?