2010-12-14 17 views
6

Me enfrento con la tarea de implementar algoritmos (principalmente estilo de lógica de negocios) expresados ​​como diagramas de flujo. Soy consciente de que los diagramas de flujo no son la mejor representación de algoritmo debido a su propiedad de código de spaghetti (¿sería esto un caso de uso para CPS?), Pero estoy atascado con la especificación expresada como diagramas de flujo.Representar Algoritmos especificados en el Diagrama de Flujo en Haskell

Aunque pude transformar los diagramas de flujo en representaciones equivalentes más apropiadas antes de implementarlos, eso podría dificultar "reconocer" el organigrama original en la implementación resultante, así que esperaba que haya alguna manera de representar directamente el diagrama de flujo -algoritmos como EDSL (tal vez monádicos) en Haskell, por lo que la apariencia de la especificación original del diagrama de flujo sería (más) obvia.

Respuesta

4

Una posible representación de diagramas de flujo es mediante el uso de un grupo de funciones mutuamente recursivas, traduciendo "ir al paso X" en "evaluar la función X con estado S". Para una mejor legibilidad, puede combinar en una sola función tanto la acción (una función externa que cambia el estado) como la cadena de if/else o la coincidencia de patrones que ayuda a determinar qué paso tomar a continuación.

Esto supone, por supuesto, que sus diagramas de flujo deben ser codificados (a diferencia de los cargados en el tiempo de ejecución desde una fuente externa).

+0

Bueno, no lo escribí en la pregunta original, pero así es como lo estoy haciendo ahora que falta para mejores ideas (que puedo hacer en cualquier idioma con soporte de recursión de cola), esperaba que hubiera algo más Haskell-ish; y sí, se supone que están codificados – hvr

+0

@hvr, creo que esta idea es limpia y una codificación bastante directa. Usted se ha definido a sí mismo a partir de una solución Haskellish, porque los programas Haskellish no piensan en términos de flujo de control. – luqui

1

Suena como Arrows encajaría exactamente con lo que describes. O haz una visualización de las flechas (debería ser bastante simple) o genera/transforma el código de la flecha de los gráficos de flujo, si es necesario.

+1

Estaría desconfiando de las flechas aquí; el diagrama de flujo es para * flujo de control * - captura de flechas * flujo de datos *. – sclv

1

Suponiendo que hay un estado "global" dentro del diagrama de flujo, entonces tiene sentido empacar en una mónada de estado. Al menos entonces, a diferencia de cómo lo está haciendo ahora, cada llamada no necesita ningún parámetro, por lo que se puede leer como a) modificar el estado, b) condicional en el estado actual, saltar.

Cuestiones relacionadas