Author: Christian.Queinnec@lip6.fr

## Introduction

Le développement d'applications dans un langage donné nécessite très souvent de devoir intégrer des bibliothèques provenant d'autres langages. Cela pour deux raisons principales :

- utiliser des bibliothèques impossibles à écrire dans ce langage, c'est-à-dire étendre les fonctionnalités ;
- utiliser des bibliothèques performantes mises en oeuvre dans d'autres langages.

Une application devient alors un assemblage de briques logicielles provenant de différents langages, où chaque brique spécialisée a été écrite dans le langage adéquat pour traiter une partie du problème. Celles-ci interopèrent entre elles pour la communication de valeurs et la demande de calculs.
Le langage Objective CAML possède un tel mécanisme d'interopérabilité avec le langage C. Il permet d'appeler à partir d'Objective CAML des fonctions C, avec arguments, et de récupérer en Objective CAML le résultat du calcul. De même l'inverse est possible. Un programme C peut déclencher un calcul en Objective CAML et travailler ensuite sur le résultat.
Le choix du langage C apparaît judicieux pour les raisons suivantes :

- c'est un langage normalisé (C ANSI) ;
- il est utilisé pour implanter les systèmes d'exploitation (Unix, Windows, MacOS, etc. ) ;
- de très nombreuses bibliothèques sont écrites en C ;
- la plupart des langages possèdent une interface avec C, ainsi il sera possible de s'interfacer avec cet autre langage en passant par C.

On peut donc voir le langage C comme un espéranto des langages de programmation.
La coopération entre C et Objective CAML soulève un certain nombre de difficultés que nous passons en revue ci-dessous.

- représentation mémoire des valeurs
  Par exemple les valeurs de base (int, char, float) des deux langages n'ont pas la même représentation mémoire. Il sera nécessaire de les convertir dans les deux sens. Il en est de même pour les valeurs structurées comme les enregistrements, les types sommes ou les tableaux.
- GC d'Objective CAML
  Bien qu'il soit possible d'implanter un tel mécanisme en C, celui-ci n'en possède pas dans la définition de sa norme. Il ne faut donc pas que l'appel d'une fonction C fasse des modifications mémoire incompatibles avec le GC d'Objective CAML.
- ruptures de calcul
  Les deux langages ne possèdent pas le même mécanisme d'exceptions, ce qui introduit un problème pour le récupérateur d'exceptions d'Objective CAML.
- partage de ressources communes
  Comme par exemple les tampons d'entrées-sorties qui ne sont pas partagés et ne rendent donc pas compte de la séquentialité des entrées-sorties des deux mondes.

Les applications développées en Objective CAML bénéficient des qualités dues à la sûreté du typage et de la gestion automatique de la mémoire. Une bonne utilisation de bibliothèques C ou de l'interfaçage via C avec d'autres langages ne doit pas mettre en danger cette sûreté. Il faudra donc suivre des règles assez strictes pour que les deux langages cohabitent harmonieusement.