Introduction

Why you should absolutely definately maybe include an F# project in your
solution.

Vidar Løvbrekke Sømme
- http://zbz5.net
- @vidarls
- http://github.com/vidarls
- vidar.l.somme@gmail.com

Vetserve AS
How it all started...
Value objects, the tiresome way

Value object in C#

- Failing Equality tests
Value object with IEquality implemented
FSharp value object

Implements:
- IEquatable<T>
- IComparable<T>
And then some

ToString override added for interop pretty print
Features

- First class functions
** Composing
** Piping
** Currying

- Immutable by default
** Binding rather than assigning
** Explicitly make mutable

- Generic by default
- Type inference
- Pattern matching
- Discriminated unions
CLR interoperability

- Consumable by other CLR languages
** F# specifics looks weird and need references to f# libraries

- F# is just a dll (FSharp.Core.dll)
** F# does not need to be installed to deploy
** Requires more for compile

- Modules with functions are static classes and methods to other
languages.

- Types are classes
Quirks and subtle differences

- Single = for equality (C# uses double ==)
- Explicit interface implementation (C# does implicit interface
implementation
- F# projects needs to be compiled before they can be used in other
projects
- F# functions are not interchangeable with C# Action or Func
Implementing interfaces

Interfaces needs to be implemented explicitly and consumed explicitly
F# as a unit testing language
I forgot to mention

That Interfaces can be implemented in an expression. Does not require a
type definition
Bonus features

Expressive as a testing language

Type providers
- Type safe access to data

Agent / Actor programming with mailboxes
Type providers are quite cool
Online resources

http://www.tryfsharp.org/
- Online interactice tutorials

http://fsharpforfunandprofit.com/
- Good introduction and in depth explanations

MSDN (http://msdn.microsoft.com/en-us/library/dd233154.aspx)
- Nice reference
Merge branch 'code'
Readme