[Caml-list] Creating ocaml libraries

[Caml-list] Creating ocaml libraries

[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 pervasives.ml, 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?

One last question: could the VFS.ml 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.?

Kindest Regards,

Jonathan

Re: [Caml-list] Creating ocaml libraries

[Gerd Stolpmann]

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 pervasives.ml, 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 VFS.ml 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
= Pervasives_kernel.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 =
object
  method output_string : string -> int -> int -> int
  method close_in : unit -> unit
  ...
end

and in_channel_provider =
object
  method open_in : string -> in_channel
  ...
end

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,
etc.

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
stdlib.

Hope these ideas help you.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Telefon: 06151/153855                  Telefax: 06151/997714
------------------------------------------------------------