10:10 Chouser: (contains? [1 2] 0.5) ==> true
10:11 which is fine, I guess, since ([1 2] 0.5) ==> 1
10:30 rhickey: Chouser: no, that seems bogus, but there's no efficient test for integer, need to check for Integer, Long, BigInteger etc...
10:49 Chouser: containsKey already does ((Number) key).intValue()
10:49 would comparing that to key work?
10:50 rhickey: sure, the problem is not the logic, it's the cost. there generic math, rebox etc
10:54 Chouser: (find [:a :b] 1/2) ==> [1/2 :a]
12:38 rhickey: how did you not just give up halfway through your dozen'th implementation of Iterator
12:39 * Chouser slogs through APersistentVector$Seq
12:42 rhickey: Chouser: the payoff is big, all of Clojure's generality, but yeah...
13:05 made vectors enforce integer keys - rev 1036
14:20 jgracin: I wonder why slime-eval doesn't work... (slime-eval '(+ 1 2)) throws "evaluation aborted". Consistently.
14:22 I should probably use some variant which sends strings because Emacs won't be able to read Clojure's exprs anyway.
16:55 arohner: what is the best type hint for a clojure map? is that a good idea?
16:56 rhickey: no type hints are needed for any Clojure objects
16:56 arohner: oh, because they're all IFns?
16:56 rhickey: only useful for objects on which you make '.' calls
16:57 calls to maps and other Clojure data types never use reflection
16:57 arohner: ah, ok
17:16 Chouser: rhickey: was the ArraySeq Object array patch for performance on the TSP? or for some other reason?
17:18 rhickey: Perf in general - I didn't realize the Array calls were reflective, so use direct calls when it's an Object array, which is usually
17:19 Chouser: Ok. My JS port of ArraySeq has an optional length arg to allow the seq to end before the end of the array.
17:19 I use that in my variatic argument handling.
17:44 achim_p: hi! is there a smooth way of telling whether a symbol is free/bound in the current context?
17:44 right now i'm doing this: (defn free? [sym] (let [free (gensym)] (= free (try (eval sym) (catch Exception e free)))))
17:44 rhickey: resolve:
17:44 user=> (resolve 'foo)
17:44 user=> (resolve 'find)
17:46 achim_p: ah, of course ... much easier - thanks!
17:51 rhickey: but that works for vars only, not for lexically scoped bindings
17:52 rhickey: are you talking about compile time or runtime?
17:53 lexically scoped binding disappear at runtime
17:58 Chouser: heh, calling clojure.instance_QMARK_ from hand-written JS seems a little awkward.
18:19 achim_p: rhickey: "macroexpand time", i guess ... i was trying to write a defn macro with simple pattern matching, i thought about something like (let [a 10] (defn-p anything [x a] ..only x rebound in here..)), but i think i'm up a blind alley here.
22:19 Chouser: rhickey: I sure you didn't go just a little crazy with the inheritence stack?
22:19 s/I/Are you/
22:19 rhickey: how so?
22:20 Chouser: heh, dunno, just asking. IObj?
22:21 rhickey: how can you tell if something supports metadata? if not interface, you dictate derivation from concrete class - always wrong
22:22 Chouser: I think I need to match your hierarchy, for the various type predicates and such to work
22:23 always wrong? There's a chance something besides Obj will ever implement IObj?
22:23 rhickey: Var does
22:23 Chouser: ok, ok. I should know better by now than to doubt you.
22:24 rhickey: but even if it didn't, every abstraction should have an interface, else you eventually get screwed
22:24 compare java.io to java.util
22:25 * Chouser knows nothing of either
22:25 Chouser: sorry, this task is dull and I'm being unnecessarily cranky.
22:25 rhickey: java.io is a huge pain, no interfaces, not extensible, very awkward
22:26 java.util has interfaces for all core abstractions, much easier to use and extend
22:26 to the extent we have ? predicates you can implement them however you want
22:29 Chouser: hm...
22:30 we wouldn't need (instance?) to return the same results?
22:41 rhickey: at some point you have to stop short of re-implementing all of Java
22:44 Chouser: indeed
22:46 I'd like as much of boot.clj as possible to work un-altered.
22:47 rhickey: some of that can be dealt with by moving things into RT, I'd be perfectly fine with that - limiting the direct Java references