Diagramas de flujo de programación funcional

Question

Diagrama de flujo. Esta vieja y antigua práctica que ha estado en uso por más de 1000 años ahora, se nos ha impuesto a nosotros, estudiantes pobres, sin ningún tipo de utilidad (o eso creo yo). Puede funcionar bien con lenguajes imperativos que se ejecutan secuencialmente, pero ¿qué pasa con mi amada programación funcional?

Tristemente, me veo forzado a crear un diagrama de flujo para mi programa (que está escrito en Haskell).

que imaginar que es fácil que algo como esto:

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

que está a sólo 3 pasos secuenciales, ir a buscar los datos, uppercasing ella, darle salida.

Las cosas se ven peor esta vez:

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

O así:

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

bien, eso era IO, que puede manejar eso como un lenguaje imperativo. ¿Qué hay de las funciones puras?

Un ejemplo real:

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

¿Cómo le diagrama de flujo que la última?

Answer 1

No creo que el diagrama de flujo, que representan procesos (por lo tanto, cambio de estados), sea adecuado para FP, que es principalmente apátrida.

Pero creo que se puede mostrar un diagrama de circuito (?).

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

Es mejor que consulte al instructor.

Answer 2

Hm ... Puede compilar manualmente su código en una representación basada en supercombinators, y luego dibujar un diagrama de flujo de esa aplicación de supercombinators. En algunos casos, incluso es útil hacerlo, proporciona una representación visual razonable del flujo. Solo piense en un flujo de datos en lugar de un flujo de ejecución.

Answer 3

En realidad, flowcharts para su uso en el software datan de hace solo unos 60 años. (¡Y realmente, la programación, tal como la conocemos, data solo de 65!) En ese momento eran increíblemente importantes como una herramienta para planificar y desarrollar algoritmos antes de la muy tediosa y propensa a errores de "codificación".

En estos días, nuestros lenguajes de programación han alcanzado un nivel de expresividad donde la intención del algoritmo se expresa más claramente por el código en sí. (Quizás no tanto en VisualBasic, pero ciertamente en Haskell.) Por lo tanto, ninguna tienda de programación moderna usa diagramas de flujo. Sin embargo, existe visual programming languages y tiene gran éxito en algunos campos. Estos entornos están relacionados con el diagrama de flujo. Tal vez su instructor realmente se está preparando para hacer una cierta cantidad de trabajo de lenguaje de programación comparativo, y los está guiando a todos a pensar acerca de estos enfoques.

Finalmente, para su problema específico, piense de esta manera: los diagramas de flujo tradicionales demostraron principalmente el flujo de control a través de un programa, ya que ese es el tipo de código que las personas escriben en ese momento. Sin embargo, siempre hubo una cierta cantidad de flujo de datos ilustrado también. Para un programa funcional, estarás demostrando principalmente el flujo de datos.

El truco, sin embargo, es averiguar cómo ilustrar el flujo de funciones (parcialmente aplicadas) como datos. Piense en lo que tiene que hacer el diagrama de flujo para sustentar el concepto de una subrutina que puede llamarse en dos lugares ... Ahora quizás pueda crear construcciones gráficas similares para que signifiquen "la función identificada por Ⓐ fluye como el segundo argumento de filter" I Estoy imaginando un arco pequeño con la etiqueta fmap con un corte de ojo de cerradura en el lado para que Ⓐ se conecte con una flecha a.

Si nada más, piense en esto como una tarea en la exploración de representaciones alternativas de su programa, y ​​si tiene diagrama de flujo extendido (que nunca tuvo que tratar con funciones genéricas) y deje eso en claro, su instructor debería darle marcas extra!

Answer 4

La clave con los diagramas de flujo y FP es que empiezas a pensar en Flujos funcionales. Como ya sabrá, FP se basa en las funciones de funciones de llamada para realizar el trabajo. Si usted no tiene una buena imagen de lo que se va a llamar a que con la información que usted todavía va a terminar la creación de código espagueti o la creación de un montón de funciones que hacen lo mismo hacer su código muy difícil de mantener

Creación de una El gráfico estructurado de lo que planea construir con un diagrama de flujo que describa en qué orden deben suceder las cosas, terminará con un programa que es mantenible y más fácil de probar.

Para aquellos que no estén familiarizados con los Diagramas de Estructura, esta es una manera de modelar las llamadas de función de la persona que llama al receptor con los valores de envío y devolución. Con él puede navegar fácilmente si ya tiene una función recuperar datos de un archivo ie config y reutilizarlo en cualquier parte de su sistema