Lingue di programmazione funzionale del flowcharting

Question

Flowcharting. Questa antica pratica antica è in uso da oltre 1000 anni, essendo costretta a farci studenti poveri, senza alcuna utilità (o almeno così credo). Potrebbe funzionare bene con i linguaggi imperativi e in sequenza, ma per quanto riguarda la mia amata programmazione funzionale?

Purtroppo, sono costretto a creare un diagramma di flusso per il mio programma (scritto in Haskell).

immagino che sia facile per una cosa del genere:

main :: IO() 
main = do 
    someInput <- getLine 
    let upped = map toUpper someInput 
    putStrLn upped 

che è a soli 3 punti in sequenza, il recupero dei dati, maiuscolo esso, emetterlo.

Le cose sembrano peggio questa volta:

main :: IO() 
main = do 
    someInput <- fmap toUpper getLine 
    putStrLn someInput 

O come questa:

main :: IO() 
main = interact (map toUpper) 

Va bene, che era IO, è possibile gestire che, come un linguaggio imperativo. Che dire delle pure funzioni?

Un esempio reale:

onlyMatching :: String -> [FilePath] -> [FilePath] 
onlyMatching ext = filter f 
    where f name = lower ('.' : ext) == (lower . takeExtension $ name) 
     lower = map toLower 

Come ti diagramma di flusso che l'ultimo?

Answer 1

Non penso che il diagramma di flusso, che rappresenta i processi (quindi il cambiamento di stati), sia adatto per FP, che è per lo più senza stato.

Ma penso che sia possibile mostrare uno schema elettrico (?).

 ext 
     _ | ______________________________________________ 
     | |            | 
     | `-> [ '.' : ] -------> [ lower ] --.__   | 
     |          __ [ == ] -----> 
name --> [ takeExtension ] ---> [ lower ] --'   | 
     |__________________________________________________| 
           f 

Faresti meglio a consultare l'istruttore.

Answer 2

Hm ... È possibile compilare manualmente il codice in una rappresentazione basata su supercombinatori e quindi tracciare un grafico simile a un diagramma di flusso dell'applicazione di tali supercombinatori. In alcuni casi è persino utile farlo, fornisce una rappresentazione visiva ragionevole del flusso. Basti pensare a un flusso di dati anziché a un flusso di esecuzione.

Answer 3

Attualmente, flowcharts per l'utilizzo nel software risalgono a circa 60 anni. (E in realtà, la programmazione, come la conosciamo, risale a soli 65 anni!) All'epoca erano incredibilmente importanti come strumento per pianificare e sviluppare algoritmi prima della fase di "codifica" molto noiosa e soggetta a errori.

In questi giorni, i nostri linguaggi di programmazione hanno raggiunto un livello di espressività in cui l'intento dell'algoritmo è espresso più chiaramente dal codice stesso. (Forse non tanto in VisualBasic, ma certamente in Haskell.) Quindi nessun negozio di programmazione moderna usa i diagrammi di flusso.

Tuttavia, visual programming languages esistono e hanno un grande successo in alcuni campi. Questi ambienti erano legati al flowcharting. Forse il tuo istruttore si sta davvero preparando a fare un po 'di lavoro di linguaggio comparativo e ti sta portando a pensare a questi approcci.

Infine, per il tuo problema specifico a portata di mano, pensa in questo modo: i diagrammi di flusso tradizionali in primo luogo hanno dimostrato il flusso del controllo attraverso un programma, poiché questo è il tipo di codice che le persone stavano scrivendo in quel momento. Tuttavia, è sempre stata illustrata una certa quantità di flusso di dati. Per un programma funzionale, dovresti principalmente dimostrare il flusso di dati.

Il trucco, tuttavia, è capire come illustrare il flusso di funzioni (parzialmente applicate) come dati. Pensa a cosa deve fare il flowcharting per supportare il concetto di una subroutine che può essere chiamata in due punti ... Ora forse puoi creare un costrutto grafico simile a significare "la funzione identificata da Ⓐ scorre come secondo argomento di filter" I Sto immaginando un piccolo inchino etichettato fmap con un buco della serratura tagliato nel lato per Ⓐ essere collegato con una freccia a.

Se non altro, pensa a questo come ad un compito nell'esplorare rappresentazioni alternative del tuo programma - e se hai un flusso di lavoro esteso (che non ha mai avuto a che fare con funzioni generiche), e chiariscilo, il tuo istruttore dovrebbe darti marchi extra!

Answer 4

L'indizio con diagrammi di flusso e FP è che si inizia a pensare nei flussi funzionali. Come forse saprete, FP si basa su funzioni che chiamano funzioni per portare a termine il lavoro. Se non hai una buona immagine di chi chiamerà chi con quali informazioni finirai per creare codice spaghetti o creare un sacco di funzioni facendo la stessa cosa, il tuo codice sarà molto difficile da mantenere

Creazione di un Grafico strutturato di ciò che si intende costruire con un diagramma di flusso che descrive in quale ordine devono accadere le cose si finirà con un programma che è manutenibile e più facile da testare.

Per chi non ha familiarità con i Grafici struttura, questo è un modo per modellare le chiamate di funzione dal chiamante al destinatario con i valori di invio e di ritorno. Con esso puoi facilmente navigare se hai già una funzione per recuperare i dati da un file di configurazione e riutilizzarla ovunque nel tuo sistema