2014-07-06 7 views
8

Es ist mein Verständnis, dass die Konstruktoren eines Typs, die keine Felder haben, "statisch zugeordnet" sind und GHC shares these between all uses, und dass die GC will not move these.reallyUnsafePtrEquality # auf Konstruktoren mit keine Felder

Wenn das stimmt, dann würde ich Verwendungen von reallyUnsafePtrEquality# auf Werte wie False und Nothing erwarten sehr sicher zu sein (keine falschen Negative oder Positive), weil sie nur als identische Zeiger auf die einzige Instanz dieser Konstruktor dargestellt werden kann.

Ist meine Argumentation richtig? Gibt es potenzielle Fehler oder Gründe, die vermuten lassen, dass dies in naher Zukunft von GHC unsicher werden könnte?

+0

Könnte wahr sein. Auf der anderen Seite scheint für Konstrukteure ohne Felder der Performance-Gewinn über langweiliges altes '(==)' ziemlich minimal zu sein ... –

+0

@DanielWagner Mein tatsächlicher Anwendungsfall arbeitet mit den neuen CAS Primops auf Boxed Referenzen . Wenn ich die 'atomic-primops'-Bibliothek verwende, möchte ich in der Lage sein, ein' Ticket Nothing '(zum Beispiel) zu cachen und sicher zu sein, dass es nie abgestanden wird. – jberryman

+0

Sie müssen möglicherweise auch auf Plugins und dergleichen achten. –

Antwort

11

Ich schaffte es tatsächlich reallyUnsafePtrEquality zu bekommen, die falsche Sache zu tun.

Hier ist mein Minimalcodebeispiel

{-# 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 

Und etwas zu tun, wie

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

So ... ja, reallyUnsafePtrEquality noch böse ist.

+0

Bemerkenswert, dass ich absolut keine Ahnung habe ** warum ** das passiert. Gerade widerlegt diese Vermutung durch eine Kombination von dummes Glück und versuchen pathologische Fälle. Wenn jemand etwas Licht vergiessen könnte. – jozefg

+0

oh super, danke dafür. Ich war ein wenig voraus, als ich vorschlug, dass es "sehr sicher" sein könnte, da wir zumindest das Problem haben, Thunks mit Werten zu vergleichen und all die Komplikationen, die Inlining verursachen könnten. Ich würde vermuten, dass so etwas hier vorgeht, aber ich kann nicht genau sehen, was ... – jberryman

+0

Ich dachte mit 'wenn b dann ein 'anderes Just()' würde es sicherlich funktionieren. Ich habe mich geirrt. Es ist in der Tat wirklich böse :) – chi

Verwandte Themen