Si tratta di un modello di progettazione valido per una funzione principale Haskell?

8

Dopo aver sviluppato diverse applicazioni Haskell, mi sono trovato a separare rigorosamente le funzioni impure di codice e fessibile ( parziale ) dal loro puro & totale controparti. Questi sforzi hanno notevolmente ridotto i costi di manutenzione associati alle applicazioni. Mi sono trovato nel tempo a fare affidamento sulla stessa struttura di alto livello main per far rispettare questa segregazione.

In generale, il mio main avrà la seguente struttura:

import System.Environment

data ProgramParameters = P ()
data ComputationResult = I ()

main :: IO ()
main = getArgs                           -- Collect arguments
   >>= andOrGetUserInput                 -- Collect user input
   >>= impureOrFailableComputations      -- Possible non-recoverable error(s)
   >>= either                            -- "Branch"
         putStrLn                        -- Print Any Failure(s)
         pureNotFailableComputations     -- Finish the work

andOrGetUserInput :: [String] -> IO ProgramParameters
andOrGetUserInput = undefined

impureOrFailableComputations :: ProgramParameters -> IO (Either String ComputationResult)
impureOrFailableComputations = undefined -- a composition of partial functions
                                         -- made total by catching exceptions & input errors
                                         -- in the short-circuiting ErrorT/EitherT monad

pureNotFailableComputations :: ComputationResult -> IO ()
pureNotFailableComputations = undefined  -- a composition of total functions

L'obiettivo è quello di combinare calcoli parziali in una monade, creando un calcolo monadico totale.

Questo è diventato uno schema nella base di codice, e vorrei un feedback sul fatto che si tratti di un schema di progettazione o un anti-pattern .

  • È un modo idiomatico per separare e amp; prendere calcoli parziali?

  • Ci sono notevoli svantaggi in questa segregazione di alto livello?

  • Esistono tecniche di astrazione migliori?

posta recursion.ninja 18.09.2014 - 18:53
fonte

1 risposta

7

Questo design presenta diverse ipotesi non banali:

  • L'input dell'utente non dipenderà dai risultati di calcoli puri o impuri.

  • I calcoli impuri non dipenderanno dal risultato dei calcoli puri.

  • La logica del programma non si ripeterà; verrà eseguito solo una volta.

Il mio altro commento sulla struttura è che non è necessario separare i calcoli puri e impuri. Il sistema di tipi di Haskell lo fa già per te.

Detto questo, questa struttura sembra certamente utile per alcune classi di programmi, specialmente se sei sicuro che le ipotesi che ho delineato sopra siano valide per il tuo programma. Non è qualcosa che ogni programma dovrebbe usare, però.

    
risposta data 18.09.2014 - 20:47
fonte

Leggi altre domande sui tag