Exercises in Programming Style–Spreadsheet

NOTE : read the rest of the series, or check out the source code.

If you enjoy read­ing these exer­cises then please buy Crista’s book to sup­port her work.

exercises-prog-styles-cover

Fol­low­ing on from the last post, we will look at the Spreadsheet style today.

 

Style 26 – Spreadsheet

Constraints

  • The problem is modeled like a spreadsheet, with columns of data and formulas.
  • Some data depends on other data according to formulas. When data changes, the dependent data also changes automatically.

 

Since we’re modelling the problem like a spreadsheet, let’s first define a few type alias to help us establish our domain language.

  • a column is referenced by a string – e.g. column “A”, “B”, “C”, and so on
  • a column can have explicit values, or a formula
  • a formula references one or more other columns and uses their data to calculate the display value for the column

Style26_01

We can model a Column with a union type, where a column is:

a) given explicit values; or

b) given a formula, and its display value is calculated from that formula.

Style26_02

A Spreadsheet is a collection of columns, whose value can be retrieved or updated using a ColumnRef, e.g.

let spreadsheet = Spreadsheet()

spreadsheet.[“A”] <- Choice1Of2 [| “hello”; “world” |]

let columnA = spreadsheet.[“A”] // [| “hello”; “world” |]

Note that our custom indexer accepts a Choice<DisplayValue, Formula> in its setter instead of a Column. I made this decision because Column.Formula needs both the Formula and its calculated DisplayValue, and here it shouldn’t be the caller’s responsibility to exercise the formula and calculate its DisplayValue.

Style26_03

After a column’s value is updated, we’ll recalculate the DisplayValue of all the columns in the Spreadsheet. This is a naive approach, but sufficient for the task at hand.

During this step, we’ll need to recursively evaluate the DisplayValue of the columns, sometimes a column might be evaluated multiple times if it’s referenced by several formulae. Again, there’s room for optimization here by caching previously calculated values.

Style26_04

 

Next, we’ll start inputting data into our Spreadsheet.

To make it easier to work with the Choice<DisplayValue, Formula> type, let’s add two helper functions.

Style26_05

We’ll leave column A and B blank for now.

Style26_06

Column C will use the data from Column A (all words) and Column B (stop words) to calculate all the non-stop words.

Column D will contain all the distinct words from Column C (non-stop words).

Style26_07

Column E references both Column C (non-stop words) and Column D (distinct non-stop words), and counts the frequency for each of these words.

An important detail to note here is that, positionally, each count in Column E is aligned with the corresponding word in Column D.Style26_08

Column F is where we’ll store the output of the program.

Because Column D (unique non-stop words) and Column E (counts) are positionally aligned, so we can use Array.zip to combine the two columns to calculate a sorted array of word frequencies.

Style26_09

Now that all the columns are set up, we can go back and input the text from Pride and Prejudice and the list of stop words into Column A and B respectively.

Doing so will trigger the DisplayValue of all the other columns to be recalculated.

Style26_10

Finally, we’ll take the top 25 rows from Column F and print them to complete our program.

Style26_11

 

I hope you’ve enjoyed today’s style, apologies for the lack of updates the last two weeks, I have been busy working out some stuff on a personal front. I’ll resume the two posts per week routine, which means we should finish this series in just over a month!

 

You can find the source code for this exer­cise here.

Recording and Slides for F# DSLs talk at F# |> Bristol

Here’s the recorded live stream of the F# DSLs session I did at the F# |> Bristol user group last night.

(apologies for the first few mins where I forgot to share my screen to the Hangout…)

and here’s the slides to go with the talk:

Exercises in Programming Style–Quarantine

NOTE : read the rest of the series, or check out the source code.

If you enjoy read­ing these exer­cises then please buy Crista’s book to sup­port her work.

exercises-prog-styles-cover

Fol­low­ing on from the last post, we will look at the Quarantine style today.

 

Style 24 – Quarantine

Constraints

  • Core program functions have no side effects of any kind, including IO.
  • All IO actions must be contained in computation sequences that are clearly separated from the pure functions.
  • All sequences that have IO must be called from the main program.

 

This style is similar to The One (aka Monads) style we saw earlier on. The notable difference here is that only the side-effecting IO code need to be contained, so we can interpret this as the IO Monad style.

 

Taking inspiration from the computation expression we built for The One style, we can make some modifications here.

We’ll start by declaring a generic IO<‘a> type that will encapsulate an IO action. Then we can build a computation expression around this wrapper type.

Unfortunately do is already a reserved keyword in F#, so we’ll have to make do with do’ instead (see what I did there? )

Style24_01

Now we can add a couple of helper types and methods to wrap around IO operations – such as reading from a file or printing to console – in our IO<‘a> type.

Style24_02

We need to read from files in order to extract words from Pride and Prejudice and to remove stop words, so both functions use our do’ computation expression. Notice that we’re using the aforementioned File.ReadAllText helper method, which returns an IO<string> so our do’ computation expression can bind to.

Style24_03

Other pure functions can stay as they are.

Style24_04

But, our main program will need to be contained since it needs to perform IO operations via the extractWords and removeStopWords functions.

Style24_05

Note that no work has actually been done yet.

So far, we have merely composed together what actions (IO and otherwise) we will perform when this program is run. To complete the puzzle we need one more thing – a mechanism to execute these side-effecting programs.

Something like this IO module perhaps?

Style24_06

which we can use to execute our mainProgram.

Style24_07

and voila!

Now, the IO operations (including printing to the console) will be performed along with other pure functions.

 

You can find the source code for this exer­cise here

Exercises in Programming Style–Declared Intentions

NOTE : read the rest of the series, or check out the source code.

If you enjoy read­ing these exer­cises then please buy Crista’s book to sup­port her work.

exercises-prog-styles-cover

Fol­low­ing on from the last post, we will look at the Declared Intentions style today.

 

Style 23 – Declared Intentions

Constraints

  • Existence of a run-time typechecker.
  • Procedures and functions declare what types of arguments they expect.
  • If callers send arguments of types that aren’t expected, the procedures/functions are not executed.

 

The problem of type checking is a solved problem in statically typed languages, so by programming in F# there’s almost nothing we need to really do for this style.

Using the same solution from the Pipeline (aka functional) style, I have added a few explicit type declarations to better comply with the constraints.

Style23_01

 

You can find the source code for this exercise here.

Exercises in Programming Style–Passive Aggressive

NOTE : read the rest of the series, or check out the source code.

If you enjoy read­ing these exer­cises then please buy Crista’s book to sup­port her work.

exercises-prog-styles-cover

Fol­low­ing on from the last post, we will look at the Passive Aggressive style today.

 

Style 22 – Passive Aggressive

Constraints

  • Every single procedure and function checks the sanity of its arguments and refuses to continue when the arguments are unreasonable, jumping out of the function.
  • When calling out other functions, program functions only check for errors if they are in a position to react meaningfully.
  • Error handling occurs at higher levels of function call chains, wherever it is meaningul to do so.

 

We have seen two contrasting approaches to handling exceptions recently:

  • Constructivist style where we always provide fallback values to allow program to continue
  • Tantrum style where we always throw exceptions to terminate program right away

Despite their different responses to exceptions, both styles share something in common – that they deal with exceptions at the callsite. Today’s style differs in this regard. Here, we’ll only consider the happy path and allow exceptions (that we can’t deal with meaningfully in the function) to escape and bubble up to a function that’s higher up in the call chain and CAN handle it in a meaningful way.

 

We’ll keep the solution to the same structure as the last two styles, but notice that we’re not explicitly handling file exceptions in extractWords and removeStopWords.

Style22_01

Style22_02

Style22_03

However, any escaped exceptions will be handled and logged by the top-level function.

Style22_04

 

If you come from a .Net or Java background, this is probably the style that you’ll most often encounter in the wild. If you’re an Erlang developer, this style perfectly embodies Erlang’s famous Let it Crash mantra!

However, you shouldn’t confuse the Passive Aggressive style with “controlling program flow using exceptions”, which points to a specific anti-pattern, like this example.

I generally prefer the Passive Aggressive style, although it doesn’t have to be mutually exclusive to the Constructivist and Tantrum styles. For example, you might leave exception handling to a function that’s higher up in the call chain, who then in turn return a fallback value for the whole chain.

As a side note, I also discovered a while back that there’s a non-trivial performance overhead associated with throwing (lots of) exceptions (another argument against using exceptions to control program flow) as the CLR needs to collect lots of runtime diagnostic information for each exception.

And finally, another often-missed observation about exceptions is that, they are really another form of GOTO.

Style22_05

 

You can find the source code for this exercise here.

 

Links