Calisthenics? Where we're going we don't need calisthenics

module Finance =
  module Currencies =
    type Currency =
      | GBP
      | USD
      | EUR

    type ExchangeRate =
      | Rate of float

      static member (/)(Rate a, Rate b) = (a / b) |> Rate

    module ExchangeRate =
      let get =
        function
        | GBP -> Rate 1.0
        | USD -> Rate 1.6
        | EUR -> Rate 1.2

    let private (>>=>) source destination =
      ExchangeRate.get source
      / ExchangeRate.get destination

    type Money =
      { Amount: int
        Currency: Currency }
      static member (+)(local: Money, other: Money) =
        let applyRate amount =
          function
          | Rate rate -> ((amount |> float) / rate) |> int

        other.Currency >>=> local.Currency
        |> applyRate other.Amount
        |> fun amount ->
              { Amount = local.Amount + amount
                Currency = local.Currency }


  module Trading =
    open Currencies

    type Transaction =
      | Incoming of Money
      | Outgoing of Money

    // The "money" function I skipped before, I found a use for it now.
    let money =
      function
      | Incoming incoming -> incoming
      | Outgoing outgoing -> outgoing

    // Ended up understanding that my "I see where I'm going" was wrong,
    // introduced a first class collection for transactions.
    type Transactions = Transactions of Transaction list

    let transactionList =
      function
      | Transactions transactions -> transactions


  module Accounting =
    open Currencies
    open Trading

    // The aforementioned entity, which will replace the Items collection suggested in the excercise.
    type Balance =
      { Transactions: Transactions
        LocalCurrency: Currency }

    let isIn currency transaction =
      transaction
      |> money
      |> fun money -> money.Currency = currency

    let isNotIn currency = isIn currency >> not

    let amount currency transactions =
      let aggregate acc trx = acc + (trx |> money)

      ({ Amount = 0; Currency = currency }, transactions)
      ||> List.fold aggregate

    let add transaction balance =
      balance.Transactions
      |> transactionList
      |> fun transactions ->
          { balance with
              Transactions = Transactions <| transaction :: transactions }


  module Taxes =
    open Accounting
    open Trading

    // It became obvious that the point of these functions was to get amounts to
    // be taxed or not.
    let taxableAmount balance =
      amount
        balance.LocalCurrency
        (balance.Transactions
         |> transactionList
         |> List.filter (isIn balance.LocalCurrency))

    let taxFreeAmount balance =
      amount
        balance.LocalCurrency
        (balance.Transactions
         |> transactionList
         |> List.filter (isNotIn balance.LocalCurrency))


  module Profits =
    open Accounting
    open Taxes

    let add transaction balance = balance |> add transaction

    let calculateTax balance =
      match taxableAmount balance with
      | money when money.Amount < 0 -> { money with Amount = 0 }
      | money ->
        { money with
            Amount = ((money.Amount |> float) * 0.2) |> int }

    let calculateProfit balance =
      let tax = calculateTax balance

      taxableAmount balance
      + taxFreeAmount balance
      + { tax with Amount = -tax.Amount }

// Then, the longest test to illustrate a point I'll make later:
// In functional programming, we are in control of the flow.
[<Fact>]
let ``Everything is reported in the local currency`` () =
  // Every piping takes the result of the previous addition and
  // passes it to the next call. We own the data flow, we do every
  // operation with the result of the previous one.
  let balance =
    eurBalance
    |> Profits.add (Incoming { Amount = 400; Currency = GBP })
    |> Profits.add (Outgoing { Amount = -200; Currency = USD })
    |> Profits.add (Incoming { Amount = 200; Currency = EUR })

  Assert.Equal({ Amount = 491; Currency = EUR }, Profits.calculateProfit balance)
  Assert.Equal({ Amount = 40; Currency = EUR }, Profits.calculateTax balance)

So, what about calisthenics?

1. Only One Level Of Indentation Per Method ✅

   When it comes to the problem this point tries to solve: cognitive load, it complies. Every line is an expression that collapses into a single type of value and every branch can be read independently of the rest of the function. In fact, everything that is indented is technically a single line, it's just a code convention indentation.

   I did consider "cheating" and making them one liners, but it makes the code less readable, defeating the goal of reducing cognitive load.

2. Don’t Use The ELSE Keyword ❔

   "Technically" not met, because there's quite a bit of pattern matching around and that's equivalent to switches with a simple return for every case. Again this rule is about reducing cognitive load and pattern matching does exactly that: Give you a single function to read per case, reducing the amount of code you have to load in your brain to understand what's going on.

3. Wrap All Primitives And Strings ✅

   Some cases are not even wrapping, but statically typed discriminated unions.

4. First Class Collections ✅

5. One Dot Per Line ✅

6. Don’t Abbreviate ✅

   I didn't abbreviate, but this is, and I'm not trying to start a holy war here, possibly a pointless exercise. In an impressively thorough study from 2017, the team could find no difference on time taken or quality when it came to debugging. Mind you, the study was only about bug fixing, but it's the only empirical thing I've found about it.

   It would seem like it's a matter of taste. I'm not advocating to abbreviate, mind you, if there's no difference and we are already used to not doing it, it's wasteful to change, as Miyamoto Musashi put it in "The Book Of Five Rings": Do nothing which is of no use.

7. Keep All Entities Small ✅

8. No Classes With More Than Two Instance Variables ✅

   No mutation allowed, hence no instance variables whatsoever.

9. No Getters/Setters/Properties ❌

   No such thing as setters, as records are immutable, but since logic and data live separately, records forcibly make their data readable.

   Again, the purpose of the item is not violated. Encapsulation is meant to protect from unwanted access to data, but with immutability, there's no real "access", but the creation of copies. Consumers of logic are in absolute control and functions are black boxes that take data and return data.

Seven out of nine points are thoroughly and easily met, another one is virtually met and the last one is unattainable at the core of the paradigm, but the goal chased is achieved in other way.

Functional programming is a paradigm that comes at a cost. Functional code is usually slower, the initial learning curve is quite steep and requires a complete rewiring of some hard-earned muscle memory, but the value we get out of it on a regular basis is the same we get of the most refined form of object oriented programming.

I can be a "bocachancla" but I might get away with this one.