Capitolo 1 - Twice

[arialdomartini]

Func<string, string> addBorder = block => $"*{block}*";

addBorder("hello").Should().Be("*hello*");
addBorder(addBorder("hello")).Should().Be("**hello**");

var add2Borders = addBorder.twice();

add2Borders("hello").Should().Be("**hello**");


Func<int, int> double = n => n * 2;
double(10).Should().Be(20);

var quadruple = double.twice();

quadruple(10).Should().Be(40);

[matteobertaiola]

public static Func<T, T> twice<T>(this Func<T, T> func)
{
       return new Func<T, T>(t => func(func(t)));
}

[arialdomartini]

Bravissimo @matteobertaiola!

Puoi renderla ancora più concisa, portandola a body expression e rendendo implicita la creazione della funzione, restituendo direttamente la lambda. Puoi anche togliere il public.

Se ci provi, arrivi a un'espressione mimina, che in C# non può essere ridotta ulteriormente.

[matteobertaiola]

public static Func<T, T> twice<T>(this Func<T, T> func) => new Func<T, T>((t) => func(func(t)));

[arialdomartini]

Esatto, @matteobertaiola . E si può fare ancora qualche passetto aggiuntivo.

Riparto da capo, giusto per vedere ogni passo separatamente.

La tua implementazione originale era:

public static Func<T, T> twice<T>(this Func<T, T> func)
{
    return new Func<T, T>(t => func(func(t)));
}

• Possiamo rimuovere public (non stiamo ancora esportando la funzione in altri progetti)

static Func<T, T> twice<T>(this Func<T, T> func)
{
    return new Func<T, T>(t => func(func(t)));
}

• Passiamo a body expression:

static Func<T, T> twice<T>(this Func<T, T> func) =>
    new Func<T, T>(t => func(func(t)));

In effetti, che informazione stavano trasportando le parentesi? Nessuna, come in una if con una singola linea. Anche il return: in FP ritorniamo sempre qualcosa, perché condannarci a scriverlo ogni volta?

• Possiamo omettere il new Func<T, T>: sia noi che il compilatore sappiamo già che il tipo ritornato sia un Func<T, T>, ripeterlo non aggiunge alcuna informazione.

Un po' come in Java, dove si era costretti a scrivere

Person person = new Person();

Per cui, puoi ritornare direttamente la lambda, e il compilatore inferirà che il tipo sia Func<T, T>:

static Func<T, T> twice<T>(this Func<T, T> func) =>
    t => func( func(t) );

Oltre qui, con C#, non si può andare.

Altri linguaggi

Se si potessero omettere i tipi, chiedendo al compilatore di inferirli, si otterrebbe:

static twice(func) =>
         t => func( func(t) );

In effetti, perché il compilatore non li capisce da sé? Quale altro tipo potrebbe mai consentire a func di essere invocato, se non una Func? E visto che gli forniamo pure il parametro t, con func(t), perché il compilatore non intuisce che sia un Func<T, ???>?

E visto che func viene applicata a sé stessa, non dovrebbe essere evidente che il tipo di ingresso e il tipo di uscita func debba essere lo stesso, che sia quindi un Func<T, T>?

In realtà, è proprio quello che i type system di F# e Haskell riescono a fare senza alcuna difficoltà.

Se si rimuovessero le parentesi, almeno dove queste sembrano superflue, si otterrebbe:

static twice func  => t => func( func t );

che è proprio la tua soluzione scritta in F#

let twice f = t => f ( f(t) )

Quello che tu dici sul rischio che un'espressione troppo concisa diventi illeggibile è molto vero. Distinguerei però tra il riassumere per il gusto di riassumere, come si potrebbe fare con le espressioni regolari o BrainFuck, che portano a codice illeggibile, e il rimuovere il superfluo, facendo emergere l'essenziale.

Io trovo che confrontando

let twice f= x => f ( f(x) )

con

public static Func<T, T> twice<T>(this Func<T, T> func)
{
    return new Func<T, T>(t => func(func(t)));
}

il secondo sia come composto da due parti:

• l'essenziale, `t => func(func(t))
• e altri elementi di contorno

e che l'essenziale sia come immerso nel contorno. Noi siamo abituati a estrarre mentalmente l'essenziale, e a ignorare il resto, ma è solo abitudine.

Invece, nell'espressione F# l'essenziale emerge e il resto è semplicemente omesso, quasi come un'espressione matematica.

Potrebbe stupirti scoprire che in F# e in Haskell si possa andare ancora oltre, con il cosiddetto Point-Free Style.

Point-Free Style

Il Point-Free Style è una modalità di manipolazione delle funzioni che tratta le funzioni come valori veri e propri, senza la necessità di far riferimento ai loro parametri.

C# la supporta in modo zoppicante. Capita quando si assegnano variabili Func

int SomeFunction(string s) { ..}

Func<string, int> foo = SomeFunction;

e, come fa notare @emanuelefirmani, quando si usano i Method Group

int Double(int i) => i * 2;
new List<int>{1,2,3}.Select(Double);

In entrambi i casi, il codice fa riferimento a delle funzioni, SomeFunction e Double, senza parlare dei loro parametri. Ma ci sta, in quel contesto i parametri sono un dettaglio che aggiunge poco al discorso.

Ma in C# non si può fare molto altro.

Sarebbe bello poter scrivere la nostra twice come:

twice(f)= f appliedTo f

In effetti è esattamente quello che si può fare in F#:

let twice f = f >> f

e in Haskell

twice f = f . f

Penso non sia possibile una versione più concisa, e comunque espressiva, di questa.

In C# potremmo pensare di avere qualcosa come

Func<int, int> double = n => n*2;

static Func<A, C> appliedTo(this Func<A, B> f, Func(B, C> g) => ....

Func<T, T> twice(this Func<T, T> f) = f.appliedTo(f);

Ecco, quel f.appliedTo(f) è Point-Free, e cattura l'essenza di twice senza fronzoli, tipi e glue code.

Per implementare appliedTo c'è un esercizio a parte.

Ma ormai dovresti sapere come risolverlo!