2014-07-06 7 views
8

È a mia conoscenza che i costruttori di un tipo che non hanno campi sono "allocati staticamente" e GHC shares these between all uses e che il GC will not move these.reallyUnsafePtrEquality # sui costruttori senza campi

Se questo è corretto allora mi aspetterei usi di reallyUnsafePtrEquality# su valori come False e Nothing essere molto sicuro (senza falsi negativi o positivi), perché possono essere rappresentati solo come puntatori identici alla singola istanza di quel costruttore.

Il mio ragionamento è corretto? Esistono potenziali trucchi o motivi per sospettare che questo potrebbe diventare pericoloso nelle prossime versioni future di GHC?

+0

Potrebbe essere vero. D'altra parte, sembra che per i costruttori senza campi le prestazioni superino il noioso vecchio '(==)' sarà piuttosto minimale ... –

+0

@DanielWagner Il mio caso d'uso attuale sta funzionando con i prim primari CAS su referenze in scatola . Quando si utilizza la libreria 'atomic-primops' mi piacerebbe essere in grado di memorizzare un' Ticket Nothing' (per esempio) e assicurarsi che non vada mai in stallo. – jberryman

+0

Potrebbe anche essere necessario fare attenzione ai plugin e simili. –

risposta

11

In realtà sono riuscito a ottenere reallyUnsafePtrEquality per fare la cosa sbagliata.

Ecco il mio esempio di codice minimo

{-# LANGUAGE MagicHash #-} 
import GHC.Prim 

-- Package it up nicely 
ptrCmp :: a -> a -> Bool 
ptrCmp a b = case (reallyUnsafePtrEquality# a b) of 
    0# -> False 
    1# -> True 

main = do 
    b <- readLn 
    let a = if b then Nothing else Just() 
     a' = Nothing 
    print $ a == a'  -- Normal 
    print $ ptrCmp a a' -- Evil 

E fare qualcosa di simile

$ ghc --version 
    The Glorious Glasgow Haskell Compilation System, version 7.8.2 
$ ghc unsafe.hs 
$ ./unsafe 
    True 
    True 
    False 

Quindi ... sì, reallyUnsafePtrEquality è ancora il male.

+0

Vale la pena notare che non ho assolutamente alcun indizio ** perché ** questo accade. Ho appena smentito questa congettura attraverso una combinazione di stupida fortuna e tentativi di casi patologici. Se qualcuno potesse fare un po 'di luce .. – jozefg

+0

oh fantastico, grazie per questo. Ho avuto un po 'di vantaggio su di me quando ho suggerito che potrebbe essere "molto sicuro", dal momento che abbiamo ancora almeno il problema di confrontare i thunk con i valori e tutte le complicazioni che l'inline potrebbe causare lì. Immagino che qualcosa del genere stia succedendo qui, ma non riesco a vedere esattamente cosa ... – jberryman

+0

Pensavo di usare 'se b poi un 'altro Just()' avrebbe sicuramente funzionato. Mi sbagliavo. È davvero davvero malvagio :) – chi

Problemi correlati