🚀 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 }
builderinstance d'un Builder📍exprpeut contenirlet,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 typeAsync<'X>seq { yield x }renvoie un typeSeq<'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
loggerBesoin : logguer les valeurs intermédiaires d'un calcul
Problèmes ⚠️
Verbeux : les
log xgĂŞnent lectureError prone : oublier un
log, logguer mauvaise valeur...
đź’ˇ Rendre les logs implicites dans une CE lors du let! / Bind :
maybe
maybeBesoin : 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 ?