🚀 Computation expression (CE)

Computation expression

Sucre syntaxique cachant une « machinerie »

  • Applique la Separation of Concerns

  • Code + lisible Ă  l'intĂ©rieur de la computation expression (CE)

Syntaxe : builder { expr }

  • builder instance d'un Builder📍

  • expr peut contenir let, let!, do!, yield, yield!, return, return!

đź’ˇ Note : seq, async et task sont des CE

Builder

Une computation expression s'appuie sur un objet appelé Builder. → Cet objet permet éventuellement de stocker un état en background.

Pour chaque mot-clé supporté (let!, return...), le Builder implémente une ou plusieurs méthodes associées. Exemples :

  • builder { return expr } → builder.Return(expr)

  • builder { let! x = expr; cexpr } → builder.Bind(expr, (fun x -> {| cexpr |}))

Le builder peut également wrappé le résultat dans un type qui lui est propre :

  • async { return x } renvoie un type Async<'X>

  • seq { yield x } renvoie un type Seq<'X>

Builder desugaring

Le compilateur opère la traduction vers les méthodes du builder.

→ La CE masque la complexité de ces appels, souvent imbriqués :

Exemples

logger

Besoin : logguer les valeurs intermédiaires d'un calcul

Problèmes ⚠️

  1. Verbeux : les log x gĂŞnent lecture

  2. Error prone : oublier un log, logguer mauvaise valeur...

đź’ˇ Rendre les logs implicites dans une CE lors du let! / Bind :

maybe

Besoin : simplifier enchaînement de "trySomething" renvoyant une Option

Bilan : ✅ Symétrie, ❌ Valeurs intermédiaires

Limites

Imbrication de CE

✅ On peut imbriquer des CE différentes ❌ Mais code devient difficile à comprendre

Exemple : combiner logger et maybe âť“

Solution alternative :

Combinaison de CE

Combiner Async + Option/Result ? → Solution : CE asyncResult + helpers dans FsToolkit

Mis Ă  jour

Ce contenu vous a-t-il été utile ?