La paresse expliquée

En Scala, la plupart des valeurs sont strictes : elles sont calculées dès que vous les définissez. L'évaluation différée inverse ce fonctionnement. Une valeur différée n'est calculée que lorsqu'elle est nécessaire pour la première fois, jamais avant.

C'est utile lorsque les calculs sont coûteux, peuvent échouer ou ne seront peut-être jamais utilisés. Pourquoi payer pour un travail que personne ne demande ?

Un val normal évalue immédiatement son membre de droite, même si vous ne le lisez plus jamais.

Exécutez ce code et remarquez que « computing » s'affiche avant « after ». Le travail est effectué au moment de la définition.

Préfixez un val avec lazy pour différer son évaluation jusqu'au premier accès.

Ici, « after » s'affiche d'abord, puis « computing » seulement lorsque x est lu. Le résultat est également mémorisé : le corps s'exécute au plus une fois.

Un paramètre déclaré comme => A est transmis par nom : l'argument n'est évalué que lorsqu'il est utilisé à l'intérieur de la méthode.

C'est le fondement de l'évaluation différée. LazyList utilise des paramètres par nom afin que sa queue ne soit jamais calculée avant d'être demandée.

LazyList est la séquence différée de Scala (elle a remplacé l'ancien Stream depuis la version 2.13). Sa tête est évaluée immédiatement, mais sa queue est différée.

Les éléments sont produits à la demande et mémorisés une fois calculés ; la même cellule n'est donc jamais recalculée deux fois.

Une LazyList reste non évaluée jusqu'à ce que vous la forciez. Appeler toList, foreach ou afficher chaque élément force les cellules.

La REPL affiche <not computed> pour la fin paresseuse. Le forçage révèle les vraies valeurs.

Vous ajoutez un élément au début d’une LazyList avec #::. Contrairement à :: des listes, l’opérande droit de #:: est évalué par nom : la fin n’est donc construite qu’en cas de besoin.

Cela vous permet de décrire des séquences dont la suite est calculée paresseusement.

Une fois qu’une cellule de LazyList est calculée, sa valeur est enregistrée. La relire ne coûte rien et l’expression qui la produit n’est pas exécutée une seconde fois.

Exécutez ceci : « calc » s’affiche uniquement lors du premier accès à chaque élément forcé, et non lors des lectures répétées.

Comme la fin est paresseuse, vous pouvez appliquer map à une LazyList et seuls les éléments auxquels vous accédez sont calculés.

Ici, « map » ne s’affiche qu’une seule fois, même si la liste contient trois éléments, car seul le premier élément est forcé.

La paresse permet d’éviter le travail inutile, de construire des séquences infinies et de dissocier la description d’un calcul de la quantité réellement exécutée.

Vous écrivez tout le pipeline une seule fois ; le consommateur décide du nombre d’éléments à extraire.

La paresse a un coût. Une LazyList mémorise ses valeurs : conserver une référence vers son premier élément maintient en mémoire chaque élément forcé. Pour des données volumineuses ou infinies, évitez de conserver le premier élément.

De plus, les effets de bord dans du code paresseux se produisent à des moments inattendus, ce qui peut compliquer le débogage.

Testez votre compréhension de l’évaluation paresseuse.

L’évaluation stricte exécute le travail immédiatement ; l’évaluation paresseuse le diffère jusqu’à ce qu’il soit nécessaire. lazy val et les paramètres évalués par nom (=> A) en sont les primitives.

LazyList s’appuie dessus : premier élément évalué immédiatement, fin paresseuse et mémorisée, forcée via toList ou l’accès à un élément. Ensuite, nous construirons des LazyLists à la main.