F# for Fun and Profit Part of the "Why use F#?" series (link)
Type inference
How to avoid getting distracted by complex type syntax
08 Apr 2012 This post is over 3 years old
As you have already seen, F# uses a technique called “type inference” to greatly reduce the number of type annotations that need to be explicitly specified in normal code. And even when types do need to be specified, the syntax is less longwinded compared to C#.
To see this, here are some C# methods that wrap two standard LINQ functions. The implementations are trivial, but the method signatures are extremely complex:
public IEnumerable<TSource> Where<TSource>( IEnumerable<TSource> source, Func<TSource, bool> predicate ) { //use the standard LINQ implementation return source.Where(predicate); } public IEnumerable<IGrouping<TKey, TSource>> GroupBy<TSource, TKey>( IEnumerable<TSource> source, Func<TSource, TKey> keySelector ) { //use the standard LINQ implementation return source.GroupBy(keySelector); } And here are the exact F# equivalents, showing that no type annotations are needed at all!
let Where source predicate = //use the standard F# implementation Seq.filter predicate source let GroupBy source keySelector = //use the standard F# implementation Seq.groupBy keySelector source You might notice that the standard F# implementations for “filter” and “groupBy” have the parameters in exactly the opposite order from the LINQ implementations used in C#. The “source” parameter is placed last, rather than first. There is a reason for this, which will be explained in the thinking functionally series.
The type inference algorithm is excellent at gathering information from many sources to determine the types. In the following example, it correctly deduces that the list value is a list of strings.
let i = 1 let s = "hello" let tuple = s,i // pack into tuple let s2,i2 = tuple // unpack let list = [s2] // type is string list And in this example, it correctly deduces that the sumLengths function takes a list of strings and returns an int.
let sumLengths strList = strList |> List.map String.length |> List.sum // function type is: string list -> int The "Why use F#?" series
- Introduction to the 'Why use F#' series
An overview of the benefits of F# - F# syntax in 60 seconds
A very quick overview on how to read F# code - Comparing F# with C#: A simple sum
In which we attempt to sum the squares from 1 to N without using a loop - Comparing F# with C#: Sorting
In which we see that F# is more declarative than C#, and we are introduced to pattern matching. - Comparing F# with C#: Downloading a web page
In which we see that F# excels at callbacks, and we are introduced to the 'use' keyword - Four Key Concepts
The concepts that differentiate F# from a standard imperative language - Conciseness
Why is conciseness important? - Type inference
How to avoid getting distracted by complex type syntax - Low overhead type definitions
No penalty for making new types - Using functions to extract boilerplate code
The functional approach to the DRY principle - Using functions as building blocks
Function composition and mini-languages make code more readable - Pattern matching for conciseness
Pattern matching can match and bind in a single step - Convenience
Features that reduce programming drudgery and boilerplate code - Out-of-the-box behavior for types
Immutability and built-in equality with no coding - Functions as interfaces
OO design patterns can be trivial when functions are used - Partial Application
How to fix some of a function's parameters - Active patterns
Dynamic patterns for powerful matching - Correctness
How to write 'compile time unit tests' - Immutability
Making your code predictable - Exhaustive pattern matching
A powerful technique to ensure correctness - Using the type system to ensure correct code
In F# the type system is your friend, not your enemy - Worked example: Designing for correctness
How to make illegal states unrepresentable - Concurrency
The next major revolution in how we write software? - Asynchronous programming
Encapsulating a background task with the Async class - Messages and Agents
Making it easier to think about concurrency - Functional Reactive Programming
Turning events into streams - Completeness
F# is part of the whole .NET ecosystem - Seamless interoperation with .NET libraries
Some convenient features for working with .NET libraries - Anything C# can do...
A whirlwind tour of object-oriented code in F# - Why use F#: Conclusion
Twitter