Ton post est tout à fait fidèle à l'idée de ma remarque sur le filtrage : c'est ce que je veux dire.
Dans les détails, moi je ne réclame pas ton "troisième comportement" (qui me semble moins bien que les deux premiers; il faudrait au moins afficher un warning) mais plutôt avoir le choix entre le premier et le second, comme fait Reia.
Par contre, il y a quelque chose d'important que j'ai aussi essayé de faire passer, c'est que les deux premiers comportements ne sont pas symétriques. C'est mieux d'avoir les deux mais, si on choisit l'un des deux, il vaut mieux choisir le premier. Choisir le second et l'imposer est un grave défaut, mais choisir le premier et ne pas permettre le second est une limitation relativement négligeable.
En effet, les deux langages considérés possèdent la possibilité d'ajouter une "garde" au filtrage. Le comportement du pattern `{X, X}` de Erlang peut facilement se réécrire en `{X, Y} ... when X == Y`. C'est moins joli, un peu plus pénible à lire et à écrire, mais c'est une modification locale : elle n'affecte que le motif, et pas le reste du code. Elle est par ailleurs plus fine puisqu'elle permet de spécifier l'égalité souhaitée (sachant qu'il n'existe en généralité pas d'égalité canonique qu'on puisse choisir naturellement et dont le comportement soit satisfaisant dans tous les cas).
Dans l'autre sens (si on ne propose que le deuxième comportement), la modification à faire pour obtenir le premier comportement est globale : il faut regarder l'ensemble de l'environnement de la fonction pour choisir des noms convenable. Une modification locale est plus coûteuse (en temps, en réflexion, en mémoire mobilisée chez le programmeur, en risque de bugs, en travail de maintenance...) donc avoir seulement ce comportement est un problème.
Heureusement, comme l'a souligné Jerome Herman, le style idiomatique Erlang encourage les fonctions plutôt courtes, qui contiennent peu de déclarations locales. La portée de l'environnement à considérer quand on analyse un motif reste donc raisonnable en pratique. Mais il n'empêche que ça reste un problème global (à l'ensemble d'une déclaration toplevel) et non local, et qu'on a donc un exemple concret où la syntaxe *gène* la sémantique.
[^] # Re: V
Posté par gasche . En réponse à la dépêche Apprendre un langage de programmation par an. Évalué à 3.
Dans les détails, moi je ne réclame pas ton "troisième comportement" (qui me semble moins bien que les deux premiers; il faudrait au moins afficher un warning) mais plutôt avoir le choix entre le premier et le second, comme fait Reia.
Par contre, il y a quelque chose d'important que j'ai aussi essayé de faire passer, c'est que les deux premiers comportements ne sont pas symétriques. C'est mieux d'avoir les deux mais, si on choisit l'un des deux, il vaut mieux choisir le premier. Choisir le second et l'imposer est un grave défaut, mais choisir le premier et ne pas permettre le second est une limitation relativement négligeable.
En effet, les deux langages considérés possèdent la possibilité d'ajouter une "garde" au filtrage. Le comportement du pattern `{X, X}` de Erlang peut facilement se réécrire en `{X, Y} ... when X == Y`. C'est moins joli, un peu plus pénible à lire et à écrire, mais c'est une modification locale : elle n'affecte que le motif, et pas le reste du code. Elle est par ailleurs plus fine puisqu'elle permet de spécifier l'égalité souhaitée (sachant qu'il n'existe en généralité pas d'égalité canonique qu'on puisse choisir naturellement et dont le comportement soit satisfaisant dans tous les cas).
Dans l'autre sens (si on ne propose que le deuxième comportement), la modification à faire pour obtenir le premier comportement est globale : il faut regarder l'ensemble de l'environnement de la fonction pour choisir des noms convenable. Une modification locale est plus coûteuse (en temps, en réflexion, en mémoire mobilisée chez le programmeur, en risque de bugs, en travail de maintenance...) donc avoir seulement ce comportement est un problème.
Heureusement, comme l'a souligné Jerome Herman, le style idiomatique Erlang encourage les fonctions plutôt courtes, qui contiennent peu de déclarations locales. La portée de l'environnement à considérer quand on analyse un motif reste donc raisonnable en pratique. Mais il n'empêche que ça reste un problème global (à l'ensemble d'une déclaration toplevel) et non local, et qu'on a donc un exemple concret où la syntaxe *gène* la sémantique.