From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA13240 for caml-redistribution; Fri, 16 Oct 1998 17:40:45 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA01200; Fri, 16 Oct 1998 17:23:36 +0200 (MET DST) Message-ID: <19981016172336.54174@pauillac.inria.fr> Date: Fri, 16 Oct 1998 17:23:36 +0200 From: Xavier Leroy To: Emmanuel.Dorlet@cea.fr, Liste-Caml Subject: Re: Primitives d'interrogations sur les types References: <3621BDB1.5F6AC02C@soleil.serma.cea.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.89.1 In-Reply-To: <3621BDB1.5F6AC02C@soleil.serma.cea.fr>; from Emmanuel Dorlet on Mon, Oct 12, 1998 at 10:28:33AM +0200 Sender: weis [English summary: infos such as "what is the type of this variable?" and "what are the methods of this class?" are not available at run-time in OCaml programs, but can be recovered from signatures of compilation units: either .mli source files or .cmi compiled interfaces.] > Pour les besoins des dévellopements autour du projet ELAN, nous > aurions (en première analyse) besoin d'accéder par programme aux > définitions des types et des objets d'un programme Ocaml: > - type (nom du type) d'une variable > - nom et type des champs d'un type structuré > - classe d'une instance > - nom et type des attributs d'une instance de classe > - méthodes d'une classe Ces informations ne sont pas attachées aux valeurs manipulées à l'exécution par un programme Caml. On conserve quelques infos de "type" de très bas niveau pour guider le GC et des primitives comme output_value, mais ce n'est pas ce que vous voulez. Les informations que vous recherchez sont bien sûr maintenues à jour et utilisées par le typeur et le compilateur. Les infos concernant les définitions exportées par une unité de compilation (un fichier .ml) sont sauvées dans le fichier .cmi correspondant. En fait, le .cmi est une représentation binaire de la signature de l'unité de compilation: ou bien celle donnée dans le fichier d'interface .mli, ou bien celle inférée par le système à partir du fichier d'implémentation .ml si aucun .mli n'est fourni. Cette signature contient toutes les infos que vous recherchez pour les définitions exportées. Les infos concernant les définitions locales à l'unité de compilation ne sont sauvées nulle part, puisqu'elles ne servent pas à typer d'autres unités de compilation. > Il semble bien que le top-level dispose de tels connaissances, puisqu'il > sait les afficher! Le toplevel a accès à toutes les informations de typage sur les définitions entrées au toplevel, ainsi qu'aux infos contenues dans les fichiers .cmi. Il utilise cette info de typage pour afficher les valeurs calculées par les phrases toplevel, en particulier. Mais encore une fois cette info de typage n'est pas attachée aux valeurs elles-même. > [Génération de code à partir de déclarations de types ou de classes Caml] > Est-ce un besoin qui vous semble raisonnable et d'un intérêt général? > Envisageriez-vous de mettre à disposition un bibliothèque d'API à ces > informations? Nous n'avons pas d'API ou d'outils tout faits pour cela. Il n'est pas difficile d'extraire des sources du compilateur un parser de fichiers .mli ou .ml, qui vous donne accès à la syntaxe abstraite des définitions de types et de classes (regarder le sous-répertoire parsing/ dans les sources.) Il est possible également d'extraire un programme pour lire les .cmi (l'info de type "pré-digérée"), bien que ces derniers utilisent des représentations internes pour les types qui sont d'emploi délicat (voir les fichiers typing/typedtree.mli, typing/env.mli et typing/ctype.mli p.ex.). Mieux vaut à mon avis repartir des fichiers source et de l'a.s.t. de parsing (parsing/parsetree.mli), beaucoup plus simple. - Xavier Leroy