¿Qué ventajas tiene StableNames sobre reallyUnsafePtrEquality #, y viceversa?

Question

datos StableName un

nombres estables tienen la siguiente propiedad: Si SN1 :: StableName y SN2 :: StableName y SN1 == SN2 SN1 y SN2 continuación, fueron creados por las llamadas a makeStableName sobre el mismo objeto.

Lo contrario no es necesariamente cierto: si dos nombres de establo no son iguales, los objetos que nombran pueden ser iguales.

reallyUnsafePtrEquality# :: a -> a -> Int #

reallyUnsafePtrEquality # devuelve si dos objetos en el montón GHC son el mismo objeto. Es realmente inseguro porque el recolector de basura mueve cosas, cierres, etc. Según mi leal saber y entender, puede devolver falsos negativos (dice que dos objetos no son lo mismo, pero lo son), pero no falsos positivos (diciendo que son lo mismo cuando no lo son).

Ambos parecen hacer lo mismo básico: pueden decirle si dos objetos son definitivamente iguales, pero no si definitivamente no lo son.

Las ventajas que puedo ver por StableNames son:

• Pueden ser hash.
• Son menos prácticos.
• Su comportamiento está bien definido y es compatible.
• No tienen realmente Inseguridad como parte de su nombre.

Las ventajas que puedo ver por reallyUnsafePtrEquality #:

• se le puede llamar directamente sobre los objetos en cuestión, en lugar de tener que crear StablesNames separadas.
• No necesita pasar por una función IO para crear los StableNames.
• No es necesario que mantenga StableNames, por lo que el uso de memoria es menor.
• El RTS no tiene que hacer la magia que sea para que StableNames funcione, por lo que el rendimiento es presumiblemente mejor.
• Tiene un nombre muy seguro y un # al final. ¡Duro!

Mis preguntas son:

• ¿Me he perdido algo?

• ¿Hay algún caso de uso donde el hecho de que StableNames esté separado de los objetos que nombran es una ventaja?

• ¿Hay uno más exacto (menos probabilidades de devolver falsos negativos) que el otro?

• Si no necesita hash, no se preocupa por la portabilidad, y no les molesta usar algo que se llama reallyUnsafe, ¿hay alguna razón para preferir StableNames a reallyUnsafePtrEquality #?

Answer 1

Sosteniendo el StableName de un objeto no evitar que sea basura recogida, mientras que sostiene el objeto en sí alrededor (para usar con reallyUnsafePtrEquality# más adelante) lo hace. Claro, puede usar System.Mem.Weak, pero en ese punto, ¿por qué no simplemente usar un StableName? (De hecho, se añadieron punteros débiles con StableName s.)

Ser capaz de hash de ellos es el principal motivador para StableName s, ya que la documentación dice:

No podemos construir una tabla hash usando la dirección del objeto como la clave, ya que los objetos se mueven por el recolector de basura, lo que significa que sería necesario un nuevo hash después de cada recolección de basura.

En general, si StableName s trabajarán para sus propósitos, que haría uso de ellos, incluso si tiene que utilizar unsafePerformIO; si realmente necesita reallyUnsafePtrEquality#, sabrá. El único ejemplo que se puede pensar en que iba a funcionar y reallyUnsafePtrEquality#StableName s no se está acelerando un costoso Eq ejemplo:

x == y = 
    x `seq` y `seq` 
    case reallyUnsafePtrEquality# x y of 
     1# -> True 
     _ -> slowEq x y 

Probablemente hay otros ejemplos que no he pensado, pero no son comunes .