Generalized Type Inference Optimization

2008-11-06 Thread Daniel Spiewak
I've been perusing Stu Halloway's beta of "Programming Clojure" and I came across the following example: (defn describe-class [c] {:name (.getName c) :final (java.lang.reflect.Modifier/isFinal (.getModifiers c))}) As demonstrated by the *warn-on-reflection* flag, Clojure is unable to determ

Re: Generalized Type Inference Optimization

2008-11-06 Thread Rich Hickey
On Nov 6, 4:31 pm, Daniel Spiewak <[EMAIL PROTECTED]> wrote: > I've been perusing Stu Halloway's beta of "Programming Clojure" and I > came across the following example: > > (defn describe-class [c] > {:name (.getName c) >:final (java.lang.reflect.Modifier/isFinal (.getModifiers c))}) > >

Re: Generalized Type Inference Optimization

2008-11-06 Thread Daniel Spiewak
> So you'd need a runtime instanceof test for Class, and use the > fastpath if true, reflection if not. > > Perf could be harder to pin down, as adding an import could cause > previously fast code to get slow. Actually, I was thinking of performing the inference based on *all* classes on the clas

Re: Generalized Type Inference Optimization

2008-11-07 Thread Rich Hickey
On Nov 6, 8:42 pm, Daniel Spiewak <[EMAIL PROTECTED]> wrote: > > So you'd need a runtime instanceof test for Class, and use the > > fastpath if true, reflection if not. > > > Perf could be harder to pin down, as adding an import could cause > > previously fast code to get slow. > > Actually, I w

Re: Generalized Type Inference Optimization

2008-11-07 Thread Daniel Spiewak
> ((String)x).length. There's no need to unify the types. There's > nothing 'bad' about the code above, that's why we're using Lisp - the > type systems are still struggling to be expressive enough. If some > third class had both methods, that would become the preferred branch. I actually hadn't