From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id IAA01111 for caml-redistribution; Thu, 4 Dec 1997 08:51:28 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA20910 for ; Wed, 3 Dec 1997 18:38:32 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id SAA04151; Wed, 3 Dec 1997 18:38:30 +0100 (MET) Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA20905; Wed, 3 Dec 1997 18:38:29 +0100 (MET) From: Pierre Weis Message-Id: <199712031738.SAA20905@pauillac.inria.fr> Subject: Re: Grammaires et pretty print In-Reply-To: <199712022058.VAA02811@jaune.inria.fr> from Daniel de Rauglaudre at "Dec 2, 97 09:58:55 pm" To: daniel.de_rauglaudre@inria.fr (Daniel de Rauglaudre) Date: Wed, 3 Dec 1997 18:38:29 +0100 (MET) Cc: Emmanuel.Engel@lri.fr, caml-list@inria.fr MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: weis > [English version further] > > > J'ai une question sur les grammaires et le pretty-print. Chaque fois > > que je doit debugger un programme, je suis toujours plus ou moin amene > > a definir des pretty printer > > ... > > De tels outils n'existent pas. Il doit y avoir une bonne raison, quel > > est le point que j'ai loupe ?? > > Le problème est que ça marche bien pour les grammaires simples. Dès > que ça se complique un peu, ça ne marche plus aussi bien. En plus, pour > peaufiner le truc, il faut ajouter des directives de pretty print > (ajouter des blancs, des breaks, etc). Effectivement, c,a ne marche bien que pour les grammaires ``injectives'', au sens ou` elles ne comportent pas de re`gles qui ge'ne`rent deux fois le me^me arbre de syntaxe abstraite (sinon a` l'inversion l'un des patrons (filtres ou patterns) devient inutile. Conside'rez par exemple une grammaire qui comporterait des ``macros syntaxiques'', c'est-a`-dire des constructions qui sont expanse'es directement lors de l'analyse syntaxique. Par exemple, la re`gle suivante permet de faire l'analyse syntaxique de l'ope'rateur boole'en &&: ... | [< e1 = expression; 'Kwd "&&"; e2 = expression >] -> If (e1, e2, Bool False) A` l'inversion, on obtiendra (au passage, notez l'emploi des nouvelles fonctionalite's du module Format avec sa nouvelle fonction printf): | If (e1, e2, Bool False) -> printf "@[%a@ &&@ %a@]" (expression) e1 (expression) e2 ce qui fait que toutes les expressions ``if then else'' avec false en partie else seront de'compile'es avec &&, ce qui n'est pas force'ment souhaitable. Plus grave encore, conside'rez des alias parfaits comme & aliasant && (comme dans la syntaxe actuelle de Caml Light et Objective Caml). On obtient: ... | [< e1 = expression; 'Kwd "&&"; e2 = expression >] -> If (e1, e2, Bool False) | [< e1 = expression; 'Kwd "&"; e2 = expression >] -> If (e1, e2, Bool False) A` l'inversion, e'videmment: | If (e1, e2, Bool False) -> printf "@[%a@ &&@ %a@]" (expression) e1 (expression) e2 | If (e1, e2, Bool False) -> printf "@[%a@ &@ %a@]" (expression) e1 (expression) e2 Le deuxie`me cas est strictement inutilisable. On a le me^me proble`me si l'on veut de'compiler un langage avec les constructions ``let'' et ``where''. > Néanmoins, je suis d'accord, personnellement, quand je fais un pretty > printer, et en particulier ceux de Camlp4, pr_o et pr_r, je les > écrits symétriquement des parseurs (mais manuellement), en reprenant > les mêmes noms de fonctions. C'est bien pratique. Mais, à mon sens, je > trouve que ça ne s'automatise pas très bien. Je suis d'accord avec toi. Cependant fournir un outil d'inversion automatique n'est pas tre`s difficile, mais pourtant tre`s utile: cela donne une premie`re approche du programme a` e'crire, qu'on fignole ensuite a` la main. A` moins qu'on ne modifie la grammaire ou la de'finition du type pour que l'outil ge'ne're le programme qu'on souhaite obtenir... > Avant tout, il manque peut-être déjà une couche au dessus de Format, > par exemple de la syntaxe pour ce module. J'ai ça dans un coin. Mais, > comme je n'utilise pas Format dans mes pretty prints de Camlp4, je > n'ai pas eu l'occasion de la bien tester. Il me semble qu'une couche au-desssus de Format n'est pas le proble`me majeur (si l'on utilise la fonction printf de Format, on a une syntaxe un peu cryptique bien su^r, mais assez compacte et simple). Le proble`me majeur est sans doute les indications d'impression (boi^tes et coupures) a` mettre dans les analyseurs syntaxiques. Mais surtout le proble`me est de savoir si ce trait en vaut la chandelle: je rappelle que nous diposions d'une syntaxe pour le formattage et d'un programme d'inversion de grammaire il y a 7 ou 8 ans, mais que ce trait a disparu sans que grand monde ne s'y oppose. > ---------- > > [Question why there are no automatic pretty printers provided with > grammars camlyacc and Camlp4] > > The problem is that it works well for simple grammars. When they > become more complicate, it is not so easy. Moreover, when you want to > ameliorate the thing, you have to add directives of pretty print > (spaces, breaks, etc). That's true. Inversion of grammars works pretty-well for ``injective grammars'', i.e. grammars with a only one rule to generate a given Abstract Syntax Tree. Otherwise, after inversion, some patterns become useless. Consider for instance a grammar with ``syntactic macros'', that is constructs that are directly expanded into the AST. For instance the following grammar rule parses the && boolean operator with direct expansion: ... | [< e1 = expression; 'Kwd "&&"; e2 = expression >] -> If (e1, e2, Bool False) Inverting this rule you get (notice the new syntax for module Format, with the new Format.printf function): | If (e1, e2, Bool False) -> printf "@[%a@ &&@ %a@]" (expression) e1 (expression) e2 This implies that all ``if then else'' with false in the else part will be decompiled as && operators application, which may be undesirable. If you add aliases, such as && and & (as in Objective Caml and Caml Light), you get the grammars rules: ... | [< e1 = expression; 'Kwd "&&"; e2 = expression >] -> If (e1, e2, Bool False) | [< e1 = expression; 'Kwd "&"; e2 = expression >] -> If (e1, e2, Bool False) If you invert these rules: | If (e1, e2, Bool False) -> printf "@[%a@ &&@ %a@]" (expression) e1 (expression) e2 | If (e1, e2, Bool False) -> printf "@[%a@ &@ %a@]" (expression) e1 (expression) e2 The second case is useless. It's even worse if you want to print a language with complex equivalent constructions (that modify the structure of the program), such as ``let'' and ``where'' constructs. > I agree with you: personnally, when I make pretty printers, e.g. those > of Camlp4, pr_r and pr_o, I write them symmetrically of the parsers > (but manually), with the same names for the functions. It is Ok. But, > according to me, I think it is difficult to automaticize. I agree as well. However, a tool inverting grammars is not so difficult to write, but still useful: this gives you a sketch of the pretty-printing program you want to write, you then have to modify it as necessary. Unless you choose to modify the grammar or the AST, until the inversion tool succeeds to generate the prettty-printing program you want... > First, I think that a layer above Format is missing, for example some > syntax for this module. I wrote something. But, because I do not use > Format for my pretty printers of Camlp4, I did not test this syntax > much. > -------------------------------------------------------------------------- > Daniel de RAUGLAUDRE > > Projet Cristal - INRIA Rocquencourt > Tel: +33 (01) 39 63 53 51 > Email: daniel.de_rauglaudre@inria.fr > Web: http://pauillac.inria.fr/~ddr/ > -------------------------------------------------------------------------- I'm afraid, I don't think that a syntax layer above Format is the major problem (if you use Format.printf, you get a admittedly strange, but compact and simple, input syntax for Format). The main problem is to add pretty-printing annotations to the grammars (include boxes and break hints to grammar rules). Moreover, the very problem is to decide if we want to write an inversion program: we had one in the very old times (7 or 8 years ago), but this feature silently desapeared from further versions of Caml. Nobody to fight for it. May be everybody is convinced that that writing a pretty-printer is just a smop. Pierre Weis INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/