2012-02-05 3 views
12

Posso disabilitare il modello non esaustivo di corrispondenze di avvertenza solo per lambda?È possibile disabilitare l'avviso di "corrispondenza del modello non esaustivo" solo per lambdas?

mi piace l'avvertimento in generale, ma non per letterali lambda effettivi in ​​questo modo:

map (\(x:xs)->...) ls 

Penso che questo codice rende abbastanza chiaro che mi aspetto che tutti i valori di ls di avere sempre almeno un elemento e non esiste un modo pulito per gestire il caso di errore nel lambda. (Immagino di poter spostare la corrispondenza del modello in una frase case, ma sarebbe semplicemente brutta.)

+0

Per farvi sapere, è generalmente una cattiva idea sopprimere gli avvertimenti come una regola empirica in qualsiasi lingua. Mi rendo conto che questo potrebbe essere sicuro, ma altre aree del tuo codice potrebbero non essere sicure, e le cose potrebbero cambiare: non vuoi essere scoperto in quelle situazioni. – AJFarmar

risposta

14

Sì, ma solo in GHC 7.2 in poi; passare -fno-warn-incomplete-uni-patterns (ad esempio nel campo ghc-options del file Cabal o in un pragma {-# OPTIONS_GHC#-} nella parte superiore del file).

Tuttavia, questo disabiliterà anche l'avviso per i collegamenti del modello, pertanto let Just x = Nothing in x non produrrà un avviso. Le istruzioni case non sono interessate.

4

Avete situazioni del genere abbastanza spesso? Questo è un codice IMHO odore. Mi piacerebbe vedere alcuni di questi lambda e sono abbastanza sicuro che possiamo fare una versione migliore che gestisca anche le liste vuote abbastanza bene. E in tutti gli altri casi potresti optare per un wrapper di tipo elenco NonEmpty.

+0

Il contesto reale era più complicato: stavo avvolgendo una funzione Haskell da utilizzare nel mio linguaggio interpretato come operatore. Il modo in cui funziona l'interprete, mi garantisce che un operatore verrà chiamato solo con esattamente due argomenti. Ho appena usato un esempio molto più semplice per l'illustrazione. –

+1

@Tikhon: capisco. Eppure potresti pensare di far riflettere i tuoi tipi sulle tue invarianti. Molto probabilmente ciò porterà a un codice più chiaro e più efficiente. Ricorda, se non puoi dimostrare (con l'aiuto del sistema di tipi) che il tuo invariante vale in tutti i casi, allora Haskell dovrà controllarli in fase di runtime. – Ingo

3

Nel caso di map, è possibile scrivere come una lista di comprensione.

[... | (x:xs) <- ls] 

Questo non produrrà alcun avviso. Sebbene, se viene visualizzato un elenco vuoto , questo verrà semplicemente filtrato anziché generare un'eccezione che potrebbe nascondere errori. Percorrere il tipo di percorso sicuro as Ingo suggests potrebbe essere un'opzione migliore se sei preoccupato per questo.

+0

La mappa era solo un esempio: nel mio codice reale, non sto utilizzando una mappa o addirittura operando su una lista necessariamente. –

+0

Mi piacerebbe notare che ho avuto [una confusione] (http://www.reddit.com/r/haskell/comments/38kl9z/thoughts_on_xlambdado_syntax/crw9y4r?context=3) sulla comprensione delle liste e sugli avvertimenti non esaustivi perché il codice come '[x | x '<- x's, let (Just x) = x'] 'non produce un avvertimento con' ghc -Wall', ma il codice si arresta in modo anomalo sui pattern mancanti. Se esegui la destrutturazione sulla lhs di '<-', allora il comportamento è più coerente, meno confuso. –

3

Vorrei andare per {-# OPTIONS_GHC -fno-warn-incomplete-patterns #-} anziché {-# OPTIONS_GHC -fno-warn-incomplete-uni-patterns #-}. E raccomanderei l'utilizzo di un approccio per file invece di inserirlo nel tuo file cabal, in genere è buona norma continuare a ricevere avvertimenti di questo tipo.