Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Creating ocaml libraries
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-11-02 (11:56)
From: Gerd Stolpmann <info@g...>
Subject: Re: [Caml-list] Creating ocaml libraries
Am Mittwoch, den 02.11.2005, 14:44 +1300 schrieb Jonathan Roewen:
> Hi List,
> I'm having a problem writing my kernel (where user apps share the same
> application space/libraries).
> The problem stems from in_channel & out_channel types. I want to map
> these onto a file system layer implemented by the kernel.
> Whilst I don't mind making small modifications to the standard library
> internals, what I don't want to have to do is build the kernel into
> the standard library...
> So, say in, I might have something like type in_channel
> = VFS.file_stream, and make all the functions that work on in/out
> channels to call VFS functions.
> Now, my question here is: how can I compile stdlib.cma without having
> to have the .cmo file(s) present? Or even written for that matter?

You mean you what to exchange one of the members of stdlib.cma? This is
not possible. If you have a stdlib_minus_pervasives.cma, you can add
pervasives.cmo with normal "ocamlc -a", however ("partial linking").

> One last question: could the implementation call functions in
> pervasives still? (Though, not the IO functions, unless there was some
> magic to not make it fall into an endless loop). Say land, lor,
> char_of_int, etc.?

I see two ways:

(1) Split modules up:

Pervasives_kernel: contains land, lor, etc. but not I/O.
Pervasives: re-exports everything from Pervasives_kernel (e.g. let land
= etc.), and adds I/O.

The problematic part are the other modules of the stdlib. Some only
depend on Pervasives_kernel (like List), so you can use them in your
kernel. Some need I/O (like Buffer), and you can use them only if you
split them, too.

(2) Pluggable I/O:

Just define the I/O types as class types, e.g.

class type in_channel =
  method output_string : string -> int -> int -> int
  method close_in : unit -> unit

and in_channel_provider =
  method open_in : string -> in_channel

Add a function to Pervasives allowing you to set the provider objects
for I/O. The function open_in now takes the current provider and calls
its open_in method to get a new in_channel.
output_string simply invokes the output_string method of the in_channel,

If you need binary compatibility to the standard version of Pervasives,
you can split the module up again in Pervasives_pluggable (with the
additional functions) and normal Pervasives.

The advantage is that you need not to modify the other modules of

Hope these ideas help you.

Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
Telefon: 06151/153855                  Telefax: 06151/997714