From: Emmanuel Engel <Emmanuel.Engel@lri.fr>
To: caml-list@pauillac.inria.fr
Subject: Gestion des librairies
Date: Wed, 26 Nov 1997 13:29:37 +0100 [thread overview]
Message-ID: <347C1631.7691@lri.fr> (raw)
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
next reply other threads:[~1997-11-26 13:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-11-26 12:29 Emmanuel Engel [this message]
1997-12-02 15:03 ` Xavier Leroy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=347C1631.7691@lri.fr \
--to=emmanuel.engel@lri.fr \
--cc=caml-list@pauillac.inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox