Je ne vais pas entrer dans le sujet pour ou contre les déclarations et vérifications statiques de types. Et je ne connais pas tellement OCaml, donc je dis peut-être des conneries dans ce qui suit... J'ajoute que du coup j'ai jeté un œil sur tout ça mais que le projet semble assez complexe et que lire du OCaml c'est assez rude (je comprends que c'est subjectif, mais de mon côté je ne vois pas d'"horreur du parenthésage" dans Lisp : les parenthèses disparaissent assez vite, il n'y a même pas besoin de les regarder).
Dans mon message je faisais remarquer que créer une structure de données (html), y ajouter du code écrit dans langage complet (pas un langage créé pour l'occasion et moins complet) et les mêler simplement ça nécessite quelques dizaines de lignes de code. Je prenais un exemple très simple à réaliser en Lisp, je n'ai pas dit qu'il n'existait pas de choses plus complexes (y compris pour écrire du javascript en Lisp ou vérifier l'arbre html). Dans le lien que tu cites, la partie Eliom seule compte 30.000 lignes de code... Dans la plupart des langages de programmation il existe des outils de génération html / de sites dynamiques, ce n'est pas ce que je mettais en avant.
Un des intérêts des macros est de permettre d'étendre la syntaxe du langage, je ne vois pas en quoi c'est un problème de conception. S'il n'y a pas de mécanisme d'extension tu peux moins écrire les choses comme tu veux. Et dans le code d'Eliom (c'est peut-être là que je n'ai pas tout compris) j'ai l'impression que des outils de compilation intégrés au langage sont utilisés. Donc pas de macros mais on utilise des outils propres aux compilateurs pour étendre la syntaxe...
Un des bouts de code en question, mais il y en a un peu partout :
(** Signature of specific code of a preprocessor. *)moduletypePass=functor(Helpers:Helpers)->sigopenHelpers.Syntax(** How to handle "{shared{ ... }}" str_item. *)valshared_str_items:Ast.Loc.t->Ast.str_itemlist->Ast.str_item(** How to handle "{server{ ... }}" str_item and toplevel str_item. *)valserver_str_items:Ast.Loc.t->Ast.str_itemlist->Ast.str_item(** How to handle "{client{ ... }}" str_item. *)valclient_str_items:Ast.Loc.t->Ast.str_itemlist->Ast.str_item[...]
[^] # Re: C'est bien dommage
Posté par ylsul . En réponse au journal C++17 est sur les rails. Évalué à 3.
Je ne vais pas entrer dans le sujet pour ou contre les déclarations et vérifications statiques de types. Et je ne connais pas tellement OCaml, donc je dis peut-être des conneries dans ce qui suit... J'ajoute que du coup j'ai jeté un œil sur tout ça mais que le projet semble assez complexe et que lire du OCaml c'est assez rude (je comprends que c'est subjectif, mais de mon côté je ne vois pas d'"horreur du parenthésage" dans Lisp : les parenthèses disparaissent assez vite, il n'y a même pas besoin de les regarder).
Dans mon message je faisais remarquer que créer une structure de données (html), y ajouter du code écrit dans langage complet (pas un langage créé pour l'occasion et moins complet) et les mêler simplement ça nécessite quelques dizaines de lignes de code. Je prenais un exemple très simple à réaliser en Lisp, je n'ai pas dit qu'il n'existait pas de choses plus complexes (y compris pour écrire du javascript en Lisp ou vérifier l'arbre html). Dans le lien que tu cites, la partie Eliom seule compte 30.000 lignes de code... Dans la plupart des langages de programmation il existe des outils de génération html / de sites dynamiques, ce n'est pas ce que je mettais en avant.
Un des intérêts des macros est de permettre d'étendre la syntaxe du langage, je ne vois pas en quoi c'est un problème de conception. S'il n'y a pas de mécanisme d'extension tu peux moins écrire les choses comme tu veux. Et dans le code d'Eliom (c'est peut-être là que je n'ai pas tout compris) j'ai l'impression que des outils de compilation intégrés au langage sont utilisés. Donc pas de macros mais on utilise des outils propres aux compilateurs pour étendre la syntaxe...
Un des bouts de code en question, mais il y en a un peu partout :