On 24.02.2010, at 15:42, Sean Devlin wrote:
> Create a local fork of Clojure, make a new branch, and hack on the
> compiler. Run the experiment, see what happens :)
Right now I have better ways to use my time than hacking on a compiler that
Rich is replacing with a new one written in Clojure!
Konrad,
Okay, I was looking in the wrong place. Which leads me to suggest the
following:
Create a local fork of Clojure, make a new branch, and hack on the
compiler. Run the experiment, see what happens :)
Sean
On Feb 24, 9:15 am, Konrad Hinsen wrote:
> On 24.02.2010, at 14:43, Sean Devlin wr
On 24.02.2010, at 14:43, Sean Devlin wrote:
> How does the reader know the difference between .hashCode
> and .reallyObsureMethod? It would need to keep a whitelist of
> everything in object, and know that these methods can be called
> directly. Maybe the reader should be upgraded to handle this
Here's what I would suspect after running the following at the REPL
user=> (set! *warn-on-reflection* true)
true
user=> (defn bar [o] (.toString o))
Reflection warning, NO_SOURCE_PATH:605 - reference to field toString
can't be resolved.
#'user/bar
user=> (bar 1)
"1"
How does the reader know the d
The following trivial code generates a reflection warning for the call
to hashCode:
(set! *warn-on-reflection* true)
(defn foo [o]
(.hashCode o))
It's easy to fix:
(defn foo [#^Object o]
(.hashCode o))
but I don't understand why a type hint for java.lang.Object could ever
be necessary
