12

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?

LukeN
  • 5,590
  • 1
  • 25
  • 33
  • 1
    How come you're forced to make a flow chart for a program in Haskell ? – David V. May 03 '10 at 14:24
  • 5
    @David: Probably something like "Assignment A: Create the following program in a language of your choice. Assignment B: Make a flowchart for your program" – sepp2k May 03 '10 at 14:30
  • Flowcharts don't work well with lazy evaluation, huh? – Johannes Rudolph May 03 '10 at 14:32
  • 1
    @sepp2k: Exactly that :) The original assigment was doing it in visual basic script, which 1) is NASTY and 2) is not available (and even if it were, I'd not use it) on linux, or a language of my choice. I choose Haskell before I knew there had to be a flowchart. The whole program is finished and document, I'm not gonna step back now :) – LukeN May 03 '10 at 14:34
  • @Johannes: Yup, that's the next problem. – LukeN May 03 '10 at 14:34
  • 7
    Assignments in VISUAL BASIC? No way your instructor will be able to judge your haskell program, I guess :-) Did you consider enrolling in a _real_ university? – Johannes Rudolph May 03 '10 at 15:01
  • 1
    Disassemble the resulting executable and flowchart that! – sigfpe May 03 '10 at 16:26
  • Johannes: Not a student YET, but I'll be in a few months :) Where I'm going to study, we'll use C++ even. – LukeN May 03 '10 at 17:10

4 Answers4

13

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.

kennytm
  • 510,854
  • 105
  • 1,084
  • 1,005
  • Yep, and those "circuit diagrams" form a category. Whatever can be put into circuit diagrams can be cast in the arrow framework in Haskell. – Alexandre C. Apr 05 '11 at 21:10
4

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!

MtnViewMark
  • 5,120
  • 2
  • 20
  • 29
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.

SK-logic
  • 9,605
  • 1
  • 23
  • 35
1

The clue with flow charts and FP is that you start thinking in Functional flows. As you may know by now FP builds on functions calling functions to get the job done. If you don't have a good image of who is going to call who with what information you still will end up creating spaghetti code or creating loads of functions doing the same thing making your code very hard to maintain

Creating a Structured Chart of what you plan to build with a flow chart describing in what order things have to happen you will end up with a program that is maintainable and easier to test.

For those unfamiliar with Structure Charts, this is a way to model function calls from the caller to the receiver with the send and return values. With it you can easy sea if you already have a function the retrieve data from a ie config file and reuse it anywhere in your system

Vincent Bevort
  • 11
  • 1