5. Les difficultés
On a vu précédemment :
- le cas du contexte englobant,
- le cas du contexte voisin.
Il reste le cas du contexte englobé.
Le principe de remplacement des environnements, « à la manière des langages à structure de blocs »; conduit à des comportements un peu imprévus.
Par exemple :
founit intuitivement la valeur 2. Elle fournira ici la valeur 3.
En effet, une vue classique d'un tel programme est une vue descendante :
on voit :
qui fait dire : « x vaut 2, y vaut x : donc y vaut 2 », et puis on a un traitement spécifique, où x vaut maintenant 3 mais y vaut 2.
On adopte ici une vue ascendante du programme :
on voit :
et on dit : « on utilise un traitement où y vaut x et x vaut 3, donc y vaut 3 », et puis on s'intéresse au contexte d'utilisation, où x vaut 2.
Ce résultat est un peu déconcertant, mais, ce qui est plus grave, il signifie qu'on peut introduire, à l'utilisation de traitements « de bas niveau », des modifications importantes sur les concepts « de haut niveau » qu'on avait préalablement dégagés. Pour se prémunir contre ce phénomène de capture, je vois deux possibilités :
- soit typer les textes, ce qui consiste à ne pas nommer le symbole "à risque" tel quel mais à l'attacher à un environnement des définitions, lequel tient lieu de type ;
- soit définir un nouvel opérateur de définition de textes, qui, contrairement à une définition habituelle, évalue ses arguments.
Dans l'un ou l'autre de ces cas, il reste que le problème n'est que partiellement résolu, puisqu'il faut malgré tout reconnaître qu'un symbole est "à risque" et le définir d'une façon un peu particulière – soit en le typant, soit en forçant son évaluation.