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