Non-numerical use cases for functional programming?

Question

I just finished reading a book on scala. What strikes me is that every single example in the whole book was numerical in some form or another.

Like a lot of programm

Answer 1

Got another one for you:

I'm involved in the very early stages of prototyping a suite of new enterprise-scale financial products intended for small-to-medium sized banks, local government, stock exchanges, etc. You're probably thinking "oh, financial code, you must be doing a lot of math" -- actually, no. These products are intended to be highly customizable and allow users to inject business rules at strategic points in the application.

We're using F# to represent and interpret business rules. To use a naive example, lets we're writing some code for check processing, we might write the rules like this:

type condition =
    | Test of string
    | And of condition * condition
    | Or of condition * condition
    | Not of condition

type transactionWorkflow =
    | Reject
    | Approve
    | AdministratorOverride of string
    | If of condition * transactionWorkflow list
         (* condition,  true condition *)
    | IfElse of condition * transactionWorkflow list * transactionWorkflow list
         (* condition,      true condition,            false condition *)
    | AttachForms of string list

Using a special application, users can write some business rules represented by the structure above. For example:

let checkProcessingWorkflow =
    [If(Test("account doesn't exist")
        ,[AdministratorOverride("Account doesn't exist. Continue?");
          AttachForms ["40808A - Null Account Deposit"]]
       );
     If(Test("deposit > 10000")
        ,[
            If(And(Test("account created within 3 months")
                   ,Test("out of country check"))
               ,[Reject]);
            IfElse(Test("account state = TX")
                    ,[AttachForms ["16A"; "16B"]]
                    ,[AttachForms ["1018"]]
                 )
         ]
       );
     Approve
    ]

So, rather than writing one business-rules engine to rule them all, we handle certain processes as a very tiny domain-specific language intepreted by F#. I'm hoping this approach will allow us to design very simple business-readable DSLs without needed to detect conflicting rules.

Of course, everything above is just concept-code, and we're still in the very earlier stages of even prototyping one of our rules system. We're using F# rather than Java or C# for one particular reason: pattern matching.