Version française
Home     About     Download     Resources     Contact us    
Browse thread
module thinning in Caml 1.06
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Francois Rouaix <Francois.Rouaix@i...>
Subject: Re: module thinning in Caml 1.06
Hi,

> Safeunix.mli:
> type sockaddr = Unix.sockaddr =

> Under 1.05, if I then compiled a module which opens Safeunix, Safeunix
> would be in its list of required interfaces (as reported by objinfo),
> but Unix would not.  Under 1.06, Unix is now a required interface, so I
> am unable to link.

The definition of "the list of required interfaces", implicitly guaranteeing
type-safe linking, has varied quite a lot in version 1.03, 1.05 and 1.06.
The full details of the story behind this are tedious. It seems, however,
that we have now reached a stable point where the computation of this list
is well understood and indeed guarantees type-safe linking (including with
Dynlink); this was not necessarily the case in previous versions of OCaml...

>From a practical point of view, when one wants to do "safe dynamic linking"
in the presence of possibly hostile bytecode, there is now only one way to
go:

1- write safe*.mli interfaces WITHOUT any reference to the original signatures,
and in particular WITHOUT type equality constraints.
The idea of using equality constraints was that you could build "towers" of
safe libraries, ie that you could write
module Unix : SafeUnix
module Foo : SafeFoo
where Foo would open Unix and SafeFoo would open SafeUnix.
The compiler had to know that SafeUnix.t = Unix.t in order to accept
that Foo : SafeFoo, if type t was used in the signature of Foo and exported
in SafeFoo.
This doesn't work anymore, as you noticed, and it will never work like before
if we want to keep guaranteeing type safe linking.

If you have only one single safe*.ml, there is no need to write equality
constraints anyway. This is just type abstraction (albeit with explicit
type definitions).
If you have multiple safe libraries, then you should:

2- catenate all safe*.mli into one single safe.mli interface (and proceed
similarly for .ml files). Compile this single safe module, and make it
available for dynlinked files. Remember that you can keep as much
module hierarchy as you need.

This is how the applet system is built in the current version of MMM
(due to be released RSN, BTW). There is a single large safe module build with
safestd (abstraction of Pervasives), safetk and friends, safestr, safeunix,
safeapplets, etc...
The applet opens Safe, and finds inside Tk, Str, Unix (the thinned versions),
etc... 

Hope it helps,
(and I realize this may be a bit confusing for the reader who has probably
never encountered this problem)

--f