caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: Jonathan Roewen <jonathan.roewen@gmail.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Creating ocaml libraries
Date: Wed, 02 Nov 2005 12:56:33 +0100	[thread overview]
Message-ID: <1130932593.4327.22.camel@localhost.localdomain> (raw)
In-Reply-To: <ad8cfe7e0511011744w74319388s7f29f5f702367031@mail.gmail.com>

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


      reply	other threads:[~2005-11-02 11:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-02  1:44 Jonathan Roewen
2005-11-02 11:56 ` Gerd Stolpmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1130932593.4327.22.camel@localhost.localdomain \
    --to=info@gerd-stolpmann.de \
    --cc=caml-list@yquem.inria.fr \
    --cc=jonathan.roewen@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).