Manoloben (./84) :
Désolé mais Ocaml c'est utilisable pour faire des vrais programme, et ca marche très bien.
Oui. Mais je te mets au défi de convaincre une entreprise d'utiliser Caml. Le langage en lui-même est bon, mais il y a plein de cas où Caml n'est pas utilisable (en dehors du problème de recruter des développeurs Caml). Pour quelqu'un qui utilise déjà .NET, F# s'intègre parfaitement dans l'existant. Un développeur Caml n'a pas de mal à migrer vers F#, les langages sont compatibles à 90%. Un développeur C# ou Java n'aura pas non plus de difficulté, puisqu'on peut coder en F# comme on le fait en C#.
Pour revenir sur les active patterns, le problème de base, c'est que le pattern matching se marie très mal avec l'objet et les abstractions. On aimerait pouvoir utiliser le pattern matching, même sur un type défini en C#. Si on veut étendre un type somme (par exemple, on ajoute un champ location dans un AST), il faut modifier la majorité des matchs. Bref, un certain nombre de problèmes se posent, notamment quand on utilise des bibliothèques externes.
Le principe des active patterns, c'est de pouvoir définir les déconstructeurs de types. Il y a un certain nombre de façons pour les définir (pour que le compilateur puisse vérifier l'exhaustivité du match quand c'est possible). Il s'utilisent ensuite de façon transparente pour l'utilisateur. Cela permet de définir plusieurs façons de déconstruire un type. Par exemple, on peut décomposer un nombre complexe sous la forme a + bi, ou bien comme un module et un argument (et ce, quelle que soit la représentation interne du type). On peut aussi faire du pattern matching sur des regexp. Le papier que j'avais cité montre un exemple pour faire du pattern matching sur le type XML de .NET, comme si c'était un type somme.
Concernant les goulots d'étranglement, ça me semble un faux problème. Les active patterns permettent surtout d'éviter les clauses when, et donc de simplifier la syntaxe. Techniquement, on peut bien sûr faire des effets de bord ou d'énormes calculs dans un active patterns, mais c'est très fortement déconseillé. De même, il est autorisé de faire plein de choses dans un accesseur en POO, mais on évite en général. C'est un peu le même problème : dès qu'on a une fonctionnalité puissante, il est possible de se tirer une balle dans le pied.
Ca fait un moment que des personnes réfléchissent sur l'association pattern matching et abstraction (il y a même eu un papier il y a 10 ans pour ajouter du pattern matching dans un langage type Java), mais F# est le premier langage à implémenter une solution robuste et complète.
Vu que C# repompe souvent les concepts de F# (cf les nouveautés de C# 3), j'espère que le pattern matching viendra dans C# 4.
