L'opérateur >|= est souvent défini comme map pour la monade, avec un order des arguments qui permet de le composer. Ainsi une définition possible est
letmapmf=bindm(funx->return(fx))let(>|=)fm=mapfm
Une manière classique, dans un contexte fonctionnel, de transformer une évaluation stricte en évaluation paresseuse est de la suspendre dans une fermeture, l'expression expr devient fun () -> expr. Ainsi l'opérateur de séquence qui en Haskell a la signature
val(>>):'at->'bt->'bt
est plus communément définit en OCaml avec la signature
val(>>):'at->(unit->'bt)->'bt
qui permet d'implémenter effectivement la séquence – l'ordre des évaluations des arguments d'une fonction ou d'un opérateur n'est pas spécifié – sauf pour les raccourcis booléens, c'est la même convention que le C si je ne me trompe pas – de sorte que la première définition ne garantirait pas que la première valeur dans l'ordre de lecture soit effectivement calculée la seconde.
On pourrait aussi bien choisir la signature
val(>>):'at->'btlazy->'bt
mais en pratique c'est la première option qui est retenue, sûrement parceque le code monadique contient beaucoup de fonctions anonymes, et que les suspensions de type fun () -> x s'y intègrent bien.
[^] # Re: Correctif
Posté par Michaël (site web personnel) . En réponse au journal Compilateur et Monad Reader. Évalué à 3.
Mais non enfin, pourquoi donc?
L'opérateur
>|=est souvent défini commemappour la monade, avec un order des arguments qui permet de le composer. Ainsi une définition possible estUne manière classique, dans un contexte fonctionnel, de transformer une évaluation stricte en évaluation paresseuse est de la suspendre dans une fermeture, l'expression
exprdevientfun () -> expr. Ainsi l'opérateur de séquence qui en Haskell a la signatureest plus communément définit en OCaml avec la signature
qui permet d'implémenter effectivement la séquence – l'ordre des évaluations des arguments d'une fonction ou d'un opérateur n'est pas spécifié – sauf pour les raccourcis booléens, c'est la même convention que le C si je ne me trompe pas – de sorte que la première définition ne garantirait pas que la première valeur dans l'ordre de lecture soit effectivement calculée la seconde.
On pourrait aussi bien choisir la signature
mais en pratique c'est la première option qui est retenue, sûrement parceque le code monadique contient beaucoup de fonctions anonymes, et que les suspensions de type
fun () -> xs'y intègrent bien.