Discussion :

[Access_to_folder]

Bonjour.

J'ai eu l'idée d'une amélioration des expressions régulières utilisées en programmation, et je cherche si elle existait déjà.

Nulle intention de remettre en question les expressions régulières, qui se sont instaurées en tant que standard, mais sont complexes, encore plus pour le débutant et surtout source d'erreurs du fait de leur faible lisibilité dans le cadre d'un travail en équipe.

Mon idée :

Décrire ce que l'on souhaite "matcher" dans un langage intelligible humain dans un langage dédié et conçu pour cela.
Ensuite, un logiciel prend la demande en entrée, et génère en sortie l'expression régulière, logiciel qui pourra être agrémenté d'option pour définir des constantes selon tel ou tel langage.

Vous me direz que cela n'a pas d'intérêt maintenant avec l'IA, car on exprime son besoin à l'IA, l'IA génère, ou prend une expression régulière existante et la modifie selon vos désirs, même plus besoin d'apprendre la syntaxe des expressions régulières.

Mais malgré tout, la syntaxe de l'expression régulière demeure peu lisible, un peu comme du code assembleur comparé à du langage impératif, où bien qu'en commentant beaucoup on puisse faire une erreur. Il y a les tests unitaires pour parer à ces mégardes me direz-vous.

Néanmoins, je reste déterminé sur l'intérêt de cette idée, qui est tout à fait intégrable en tant que code source dédié, automatisable dans un makefile ou autre, afin d'avoir une définition intelligible de ce qui est matché, et le respect du standard des expressions régulières en sortie.

Alors, avant de me lancer dans le développement, j'ai cherché si cela existait déjà. Oui.

Il y a "Human2Regex" https://human2regex.com/tutorial.html qui correspond le mieux à cette idée. Seul regret : le langage dans lequel il est concu, écrit en C/C++ aurait assuré une meilleure portabilité.

Il existe d'autres projets, mais beaucoup moins "human" : https://github.com/crdoconnor/simex et https://dottxt-ai.github.io/outlines...ity/regex_dsl/

En espérant que ce partage vous sera utile.

[Obsidian]

Merci pour ce partage, en effet.

Pour le reste, il serait bon de rappeler avant tout que les expressions régulières ne sont pas un langage de markup choisi arbitrairement mais bien un formalisme mathématique. L'étoile de Kleene, par exemple, est un astérisque qui se place normalement en exposant : « e^* » et qui signifie rapidement ici « n'importe quel exposant » (dans les entiers naturels), si bien qu'il est équivalent à « e⁰ ∪ e¹ ∪ e² ∪ e³ ∪ … » jusqu'à l'infini.

Le produit cartésien de deux ensemble consistant à associer chaque élément du premier ensemble avec successivement tous les éléments du second, élever un alphabet au carré (donc le multiplier par lui-même) permet de produire tous les mots de longueur 2 exactement. Et conséquemment, l'étoile ci-dessus désigne les mots produits à partir de l'ensemble de toutes les longueurs possibles, y compris nulle.

De même, il est démontré qu'une expression régulière qui contient des parenthèses reste une expression régulière (contrairement au langage qu'elle reconnait et qui, s'il contient des parenthèses correctement agencées, devient algébrique et passe du type 3 au type 2). Les parenthèses dans une expression ne servent donc pas qu'à définir des sous-groupes.

Dès lors, réécrire ce formalisme dans un langage « naturel » comme le fait SQL peut être une bonne idée, à condition que ce langage lui reste pleinement fidèle et qu'il garantisse l'accès à toutes les combinaisons possibles, le tout en restant aux langages réguliers (pas question de remonter jusqu'à la machine de Turing par accident). Il faut aussi voir à ne pas faire ce que fait Laravel, par exemple : fournir des API qui permettent de construire du SQL dans le désordre. C'est coller un langage humain au dessus d'un autre langage déjà humain et cela ne fait prendre que des mauvaises habitudes.

Enfin, avant de s'investir dans sa conception et son développement, il faudra voir s'il est vraiment utile à long terme ou s'il n'est pas plus facile, en définitive, d'apprendre correctement les expressions régulières dans l'intervalle car si elles sont confuses de prime abord, leur syntaxe n'est pas très étendue non plus.

[Access_to_folder]

Dès lors, réécrire ce formalisme dans un langage « naturel » comme le fait SQL peut être une bonne idée, à condition que ce langage lui reste pleinement fidèle et qu'il garantisse l'accès à toutes les combinaisons possibles,

Cela était parfaitement dans mon esprit lorsque j'ai réfléchi à cette idée.
Le fait que cela ait été déjà développé ne m'a pas fait pousser l'analyse de l'idée jusqu'à sa conclusion, d'autant plus que je n'ai pas utilisé toutes les possibilités du regex.
Reprendre la documentation des regex était prévue dans la poursuite de l'ébauche.
Néanmoins, si cela ne couvre pas toutes les possibilités, j'en reste néanmoins convaincu de l'utilité en terme de lisibilité du travail en cas de travail de groupe, raison de ce sujet de discussion pour partager cela et recueillir les critiques ; et, tel je ne précisais, ne se voulait pas à remplacer les regex fort répendues dont certaines subtilités qui ne pourraient être réalisées autrement demeureraient toujours possible via la syntaxe regex.