Flowcharting functional programming languages

Question

Flowcharting. This ancient old practice that's been in use for over 1000 years now, being forced upon us poor students, without any usefulness (or so do I think). It might work well with imperative, sequentially running languages, but what about my beloved functional programming?

Sadly, I'm forced to create a flow chart for my programm (that is written in Haskell).

I imagine it being easy for something like this:

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

Which is just 3 sequenced steps, fetching data, uppercasing it, outputting it.

Things look worse this time:

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

Or like this:

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

Okay, that was IO, you can handle that like an imperative language. What about pure functions?

An actual example:

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

How would you flowchart that last one?

Answer 1

I don't think flowchart, which represent processes (therefore change of states), is suitable for FP, which is mostly stateless.

But I think you can show a circuit diagram (?).

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

You'd better consult the instructor.

Answer 2

Hm... You could manually compile your code into a supercombinators-based representation, and then draw a flowchart-like graph of that supercombinators application. In some cases it is even useful to do so, gives some reasonable visual representation of the flow. Just think of a data flow instead of an execution flow.

Answer 3

Actually, flowcharts for use in software date back only about 60 years. (And really, programming, as we know it, dates back only 65!) At the time they were incredibly important as a tool for planning and developing algorithms prior to the very tedious and error prone stage of "coding".

These days, our programming languags have reached a level of expressiveness where the intent of the algorithm is more clearly expressed by the code itself. (Perhaps not as much in VisualBasic, but certainly in Haskell.) Hence, no modern programming shop uses flowcharts.

However, visual programming languages exist, and have great success in some fields. These environments related to flowcharting. Perhaps your instructor is really preparing to do some amount of comparative programming language work, and is leading you all to thinking about these approaches.

Finally, to your specific problem at hand, think about it this way: Traditional flowcharts primarily demonstrated the flow of control through a program, since that is the kind of code people were writing at the time. However, there was always some amount of data flow illustrated as well. For a functional program, you'd be primarily demonstrating data flow.

The trick though, is figuring out how to illustrate flow of (partially applied) functions as data. Think of what flowcharting has to do to support the concept of a subroutine that can be called in two places... Now perhaps you can create similar graphical construct to mean "the function identified by Ⓐ flows in as the second argument of filter" I'm imagining a small bow labeled fmap with a key-hole cut in the side for Ⓐ to be connected with an arrow to.

If nothing else, think of this as an assignment in exploring alternate representations of your program - and if you have extend flowcharting (which never had to deal with generic functions), and make that clear, your instructor should be giving you extra marks!