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 OAA18534 for caml-redistribution; Wed, 26 Nov 1997 14:34:07 +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 NAA17557 for ; Wed, 26 Nov 1997 13:29:42 +0100 (MET) Received: from lri.lri.fr (root@lri.lri.fr [129.175.15.1]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id NAA18369 for ; Wed, 26 Nov 1997 13:29:40 +0100 (MET) Received: from sun-demons.lri.fr (sun-demons.lri.fr [129.175.8.90]) by lri.lri.fr (8.8.5/jtpda-5.2) with ESMTP id NAA04510 for ; Wed, 26 Nov 1997 13:29:39 +0100 (MET) Received: from sun-demons by sun-demons.lri.fr (8.8.4/local) with SMTP id NAA27763 for ; Wed, 26 Nov 1997 13:29:37 +0100 (MET) Message-ID: <347C1631.7691@lri.fr> Date: Wed, 26 Nov 1997 13:29:37 +0100 From: Emmanuel Engel X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5 sun4u) MIME-Version: 1.0 To: caml-list@pauillac.inria.fr Subject: Gestion des librairies Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: weis Je me pose une question sur le cout, en terme de place, des gros modules en Caml. Dans un langage de programmation comme C, lorsque l'on souhaite ecrire une librairie, une bonne pratique est de mettre chacune des fonctions de la librairie dans un fichier separe et de transformer l'ensemble de tous ce fichiers en une seule unite a l'aide de la commande "ar". L'interet, par rapport au fait d'avoir tout mis dans un seul et meme fichier est de permettre a "ld" de ne mettre dans l'executable final que les fonctions qui sont reellement utiles. Pour Ocaml la situtation est differente et pas aussi favorable. Une telle pratique se heurte a la gestion des modules en Ocaml (un module doit etre defini dans un seul fichier). Supposons que je souhaite reimplementer le module list. Suivant le meme principe que precedement, je vais mettre une fonction par fichier: ------- list_lenght.ml ------------ let rec length_aux len = function [] -> len | a::l -> length_aux (len + 1) l let f l = length_aux 0 l ----------------------------------- ------- list_tl.ml ---------------- let f = ... ----------------------------------- etc... Je me retrouve donc avec un module par fonction. Pour voir mes liste comme une seule et meme librairie, je suis ammene a creer le module suivant: module List = struct let length = List_length.f and tl = List_tl.f and .... end et a engendrer la libraire (ocamlopt -a -o list.cmxa ...) qui enferme tous les fichiers. Notons au passage que je suis incapable d'interdire l'acces direct au fonctions List_lenght.f List_tl.f etc... Cela peut etre problematique si la librairie defini un type abstrait: pour que chaque fonction de la librairie puisse acceder librement et concretement au type je suis ammene a le rendre publique et je n'ais aucun moyen de la cacher par la suite. Sur ce principe, je me pose plusieurs questions. 1) Quels sont les benefices que je peut attendre d'une telle pratique? 2) N'est-il pas envisageable que le compilateur (natif) fasse ce genre de travail pour moi, au vol ? (i.e. genere un fichier assembleur par fonction et me retourne un couple de fichier x.cmx/x.a plutot qu'un couple de fichier x.cmx/x.o). Cela presenterait l'avantage de cacher les modules List_lenght List_tl etc.... et de permettre d'appliquer la technique a des modules qui definissent des types abstraits. -- - Emmanuel Engel