Come forzare correttamente la valutazione del valore puro in IO monade?

Question

Devo forzare la valutazione del valore puro nella monade IO. Sto scrivendo l'interfaccia di livello superiore ai collegamenti C. Al livello inferiore ho, ad esempio, la funzione newFile e la funzione freeFile. newFile restituisce qualche id, oggetto opaco che ho definito al livello inferiore. Non puoi fare praticamente nulla con questo, ma lo per usarlo per liberare il file e calcola semplicemente qualcosa associato a quel file.

Così, ho (semplificato):

execGetter :: FilePath -> TagGetter a -> IO a 
execGetter path g = do 
    fid <- newFile path -- ‘fid’ stands for “file id” 
    let x = runGetter g fid 
    freeFile fid 
    return x 

Questa è la versione iniziale della funzione. Dobbiamo calcolare x prima che venga chiamato freeFile. (Il codice funziona, se tolgo freeFile è tutto bene, ma voglio liberare la risorsa, si sa.)

Primo tentativo (useremo seq di valutazione “forza”):

execGetter :: FilePath -> TagGetter a -> IO a 
execGetter path g = do 
    fid <- newFile path 
    let x = runGetter g fid 
    x `seq` freeFile fid 
    return x 

Errore di segmentazione. Proseguire dritto alla documentazione di seq:

Il valore di seq a b è basso se a è basso, e comunque pari a b. seq viene generalmente introdotto per migliorare le prestazioni evitando la pigrizia non necessaria .

Una nota su ordine di valutazione: l'espressione seq a b non garantisce che a verrà valutato prima b. L'unica garanzia fornita da seq è che entrambi a e b verranno valutati prima che seq restituisca un valore . In particolare, ciò significa che b può essere valutato prima dello a. Se è necessario garantire un ordine specifico di valutazione, è necessario utilizzare la funzione pseq dal pacchetto "parallelo".

Una nota positiva, infatti, ho visto persone che rivendicano cose diverse sull'ordine di valutazione in questo caso. Che mi dici di pseq? Devo dipendere da parallel solo per il pseq, hmm ... potrebbe esserci un altro modo.

{-# LANGUAGE BangPatterns #-} 

execGetter :: FilePath -> TagGetter a -> IO a 
execGetter path g = do 
    fid <- newFile path 
    let !x = runGetter g fid 
    freeFile fid 
    return x 

Errore di segmentazione. Bene, that answer non funziona nel mio caso . Ma suggerisce evaluate, proviamo troppo:

Control.Exception (evaluate) 
Control.Monad (void) 

execGetter :: FilePath -> TagGetter a -> IO a 
execGetter path g = do 
    fid <- newFile path 
    let x = runGetter g fid 
    void $ evaluate x 
    freeFile fid 
    return x 

Segmentation fault. Forse dovremmo usare il valore restituito da evaluate?

Control.Exception (evaluate) 
Control.Monad (void) 

execGetter :: FilePath -> TagGetter a -> IO a 
execGetter path g = do 
    fid <- newFile path 
    let x = runGetter g fid 
    x' <- evaluate x 
    freeFile fid 
    return x' 

No, cattiva idea.Forse potremmo catena seq:

execGetter :: FilePath -> TagGetter a -> IO a 
execGetter path g = do 
    fid <- newFile path 
    let x = runGetter g fid 
    x `seq` freeFile fid `seq` return x 

Questo funziona. Ma è questo il modo giusto per farlo? Forse funziona solo a causa della logica di ottimizzazione volatile ? Non lo so. Se seq si associa in questo caso a , in base a tale descrizione, entrambi x e freeFile vengono valutati quando return x restituisce il suo valore. Ma ancora, quale di questi, x o freeFile viene valutato per primo? Dal momento che non ottengo errori di seg, è necessario essere x, ma questo risultato è affidabile? Sai come forzare la valutazione di x prima del freeFilecorrettamente?

Answer 1

Un possibile problema è che newFile sta facendo un po 'pigro IO, e che runGetter è un consumatore sufficientemente pigro che in esecuzione seq sulla sua uscita non forza tutte IO newFile s' accadere in realtà. Questo può essere risolto utilizzando deepseq invece di seq:

execGetter :: NFData a => FilePath -> TagGetter a -> IO a 
execGetter path g = do 
    fid <- newFile path 
    let x = runGetter g fid 
    x `deepseq` freeFile fid 
    return x 

Un'altra possibilità che questo indirizzo è quello runGetter è la pretesa di essere puri, ma in realtà non è (ed è un produttore pigro). Tuttavia, se questo è il caso, la correzione corretta è di non usare deepseq qui, ma per eliminare gli usi di unsafePerformIO da runGetter, quindi utilizzare:

execGetter :: FilePath -> TagGetter a -> IO a 
execGetter path g = do 
    fid <- newFile path 
    x <- runGetter g fid 
    freeFile fid 
    return x 

che dovrebbe quindi lavorare senza ulteriori giocherellare con forzatura.

Answer 2

La risposta di Daniel Wagner va bene per questo caso d'uso, ma a volte è anche utile valutare solo il dorso di una lista e lasciare gli elementi della lista non valutati (e talvolta le voci dell'elenco non hanno un'istanza ragionevole) NFData. Non è possibile utilizzare deepseq per questo perché valuta tutto. Tuttavia, è possibile combinare seq con questa funzione:

evalList :: [a] ->() 
evalList [] =() 
evalList (_:r) = evalList r