From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: Jonathan Roewen <jonathan.roewen@gmail.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Changing implementations of standard libraries...
Date: Sat, 29 Oct 2005 13:36:40 +0200 [thread overview]
Message-ID: <1130585800.15589.131.camel@localhost.localdomain> (raw)
In-Reply-To: <ad8cfe7e0510282047i50071243o960788d0c6abedad@mail.gmail.com>
Am Samstag, den 29.10.2005, 16:47 +1300 schrieb Jonathan Roewen:
> Hi,
>
> What changes does -vmthread make to the compiler when generating code?
AFAIK, the generated code is the same.
> I see vmthreads provides it's own version of pervasives for starters.
A different version of the stdlib is linked.
> Also, as long as the .cmi files don't change, one would be free to
> replace the implementation with any thing they see fit, correct?
Yes. But you cannot implement in O'Caml when the function is external
because this is part of the interface, at least if you need binary
compatibility.
> For example, for my OS project, I would probably want to change the
> implementation for the stdlib such that in_channel & out_channel would
> be implemented on top of my OCaml-based VFS layer, rather than relying
> on C code. I would assume, for example, that since in_channel is
> considered abstract in the .cmi file, I could change the actual
> implementation of the type to a custom record type -- is that correct?
Yes.
> Another example would be modifying vmthreads package to work inside an
> OCaml-based process. This would then extend to pervasives and
> stdin/out/err, so that they work correctly (from the ocaml process
> data structure's file handles, rather than some global C variables).
>
> Apart from Unix module, which I'd like to do away with, the rest of
> stdlib seems to be quite useful, just not compatible in the current
> implementation for building a kernel without requiring doing lots of
> stuff in C.
>
> I'm just not sure what to do with things like select(), and whether I
> could implement some sort of replacement in ocaml, but that's a
> separate issue entirely.
I suppose select is quite hard for an OS implementor.
Gerd
>
> Kindest Regards,
>
> Jonathan
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
--
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de
Telefon: 06151/153855 Telefax: 06151/997714
------------------------------------------------------------
next prev parent reply other threads:[~2005-10-29 11:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-29 3:47 Jonathan Roewen
2005-10-29 11:36 ` Gerd Stolpmann [this message]
2005-10-30 0:45 ` Jonathan Roewen
2005-10-30 1:12 ` Jonathan Roewen
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=1130585800.15589.131.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).