¿Cómo funciona Clojure ^: const?

Question

Estoy tratando de entender qué hace ^:const en clojure. Esto es lo que dicen los desarrolladores. http://dev.clojure.org/display/doc/1.3

(def constantes de {: pi 3,14 : e 2,71}) ​​

(def ^: pi const (: constantes pi)) (def ^: const e (: e constantes))

La sobrecarga de mirar hacia arriba: ey: pi en el mapa ocurre en tiempo de compilación, como (: constantes pi) y (constantes e) se evalúan cuando se evalúan sus formularios padre def.

Esto es confuso ya que los metadatos es para el var obligado a pi símbolo, y la var obligado a e símbolo, sin embargo, la siguiente oración dice que ayuda a acelerar las búsquedas de mapa, no las Búsquedas de var.

¿Alguien puede explicar lo que ^:const está haciendo y la razón detrás de usarlo? ¿Cómo se compara esto con el uso de un bloque gigante let o usando una macro como (pi) y (e)?

Answer 1

Eso me parece un mal ejemplo, ya que las cosas sobre la búsqueda de mapas solo confunden el problema.

Un ejemplo más realista sería:

(def pi 3.14) 
(defn circumference [r] (* 2 pi r)) 

En este caso, el cuerpo de la circunferencia se compila en código que elimina referencia pi en tiempo de ejecución (llamando Var.getRawRoot), cada circunferencia tiempo se llama.

(def ^:const pi 3.14) 
(defn circumference [r] (* 2 pi r)) 

En este caso, la circunferencia se compila en exactamente el mismo código como si hubiera sido escrito así:

(defn circumference [r] (* 2 3.14 r)) 

Es decir, la llamada a Var.getRawRoot se omite, lo que ahorra una un poco de tiempo Aquí es una medición rápida, donde circ es la primera versión anteriormente, y CIRC2 es la segunda:

user> (time (dotimes [_ 1e5] (circ 1))) 
"Elapsed time: 16.864154 msecs" 
user> (time (dotimes [_ 1e5] (circ2 1))) 
"Elapsed time: 6.854782 msecs" 

Answer 2

En los documentos de ejemplo, intentan mostrar que en la mayoría de los casos si def una var es el resultado de buscar algo en un mapa sin usar const, la búsqueda se realizará cuando la clase se cargue. por lo que paga el costo una vez cada vez que ejecuta el programa (no en cada búsqueda, solo cuando se carga la clase). Y pagar el costo de buscar el valor en la var cada vez que se lee.

Si por el contrario lo hace const entonces el compilador preformas de las operaciones de búsqueda en tiempo de compilación y luego emiten una última variable sencilla Java y tendrá que pagar el costo total de las operaciones de búsqueda sólo una vez en el momento de compilar el programa.

Este es un ejemplo artificial porque una consulta de un mapa en tiempo de carga de clases y algunas operaciones de búsqueda var en tiempo de ejecución son básicamente nada, aunque ilustra el punto de que algunos trabajos que sucede en tiempo de compilación, algunos en tiempo de carga, y el resto también. .. el resto del tiempo

Answer 3

Además del aspecto eficiencia se ha descrito anteriormente, hay un aspecto de seguridad que también es útil.Considere el siguiente código:

(def two 2) 
(defn times2 [x] (* two x)) 
(assert (= 4 (times2 2))) ; Expected result 

(def two 3)     ; Ooops! The value of the "constant" changed 
(assert (= 6 (times2 2))) ; Used the new (incorrect) value 

(def ^:const const-two 2) 
(defn times2 [x] (* const-two x)) 
(assert (= 4 (times2 2))) ; Still works 

(def const-two 3)   ; No effect! 
(assert (= 3 const-two)) ; It did change... 
(assert (= 4 (times2 2))) ; ...but the function did not. 

Así, mediante el uso de la ^: const en la definición de metadatos VARs, los VARs son efectivamente "inline" por todos los lugares que se utilizan. Cualquier cambio posterior en la var, por lo tanto, no afecta a ningún código donde el valor "anterior" ya haya sido inlineado.

El uso de ^: const también sirve para una función de documentación. Cuando uno lee (def ^: const pi 3.14159) le dice al lector que la var pi no tiene la intención de cambiar, que es simplemente un nombre conveniente (& con suerte descriptivo) para el valor 3.14159.

Dicho lo anterior, tenga en cuenta que nunca uso ^:const en mi código, ya que es engañoso y proporciona "falsa seguridad" de que una var nunca cambiará. El problema es que ^:const implica que no se puede redefinir una var, pero como vimos con const-two, no impide que se cambie la var. En su lugar, ^:const oculta el hecho de que la var tiene un nuevo valor, ya que const-two ha sido copiado/en línea (en tiempo de compilación) a cada lugar de uso antes de que se cambie la var (en tiempo de ejecución).

Una solución mucho mejor sería arrojar una excepción al intentar cambiar una var ^:const.