From: Christophe Raffalli <raffalli@univ-savoie.fr>
To: Brian Hurt <bhurt@spnz.org>, caml-list@inria.fr
Subject: Obj or not Obj
Date: Mon, 28 Nov 2005 01:17:46 +0100 [thread overview]
Message-ID: <438A4CAA.6070006@univ-savoie.fr> (raw)
In-Reply-To: <Pine.LNX.4.63.0511251920510.24132@localhost.localdomain>
>
> As a general rule, unless you work at INRIA, you should never, ever
> use the Obj module. Not only will the code be signifigantly less
> readable, it'll also be signifigantly more error prone, especially
> obscure, hard to debug unless you are intimately familiar with the
> inners of the garbage collector, segfault you program at random times,
> boy doesn't this feel like C++ bugs.
>
As nicolas Canasse already said this is a too strong statement, that
should/could be commented by somone else at INRIA
(otherwise, make install should not install obj at all ;-). Here are a
few reason
- using Obj requires the same knowledge as writing C interface ... and C
is more obscure that OCaml's code with Obj.
For instance, my bindlib library for bound variables would be much more
error prone in C .. and by the way what do you think of
software distributed as patch for Ocaml like FreshOcaml ...
- then Obj is sometimes necessary, typically
- when trying to have OCaml accept programs that it thinks wrongly to
be not typable (like programs extracted from Coq proof)
- when you have an "environment" (list, array, etc ...) that needs to
contain variables of various AND unknown type (unkown because you are
writing libraries or general tools, this is the case of bindlib,
code genarated by ocamlyacc and many others). Moreover, all these programs
would be typable using dependent types ...
- for all the examples above using C would be stupid ! especially for
ocamlyacc ;-)
Nevertheless, I almost agree, you should just make sure before using Obj
that
- you read and learn a lot about the runtime
- you can not find another way round, even if it cost a little time
Just a small word about one of my bad experiment with Obj about tail rec
map ... it is easy to get a tail
rec map using Obj to make ocaml's list mutable ... it is just slower
that the original map and using roughly the same
amount of memory, because every cons cell you gain ... is now in the
list of grey val as soon as your list does not
fit in the minor heap anymore !! So even writing you own mutable_list
type would be as bad !
Explanation: the list of grey val is a list of pointers from the major
heap to the minor heap which
are created when using mutable data structure and which would break
incremental GC if each minor GC did not scan
the list of grey val) ...
This also does mean that you should know a lot about the runtime when
using mutable data structures and caring about performance !!
So Obj or not Obj (or mutable or not mutable) is always a hard question
that needs time ...
but definitely, I think the above sentence is too strong.
next prev parent reply other threads:[~2005-11-28 0:17 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-25 23:53 Efficency of varient types Michael D. Adams
2005-11-26 0:31 ` [Caml-list] " Nicolas Cannasse
2005-11-26 1:22 ` Brian Hurt
2005-11-26 9:39 ` Nicolas Cannasse
2005-11-28 0:17 ` Christophe Raffalli [this message]
2005-11-28 8:41 ` [Caml-list] Obj or not Obj Nicolas Cannasse
2005-11-28 9:27 ` Christophe Raffalli
2005-11-28 9:33 ` skaller
2005-11-28 8:43 ` Alain Frisch
2005-11-26 2:54 ` [Caml-list] Efficency of varient types skaller
2005-11-27 5:06 ` Michael D. Adams
2005-11-27 5:45 ` Brian Hurt
2005-11-27 10:02 ` Nicolas Cannasse
2005-11-27 15:35 ` Michael D. Adams
2005-11-27 18:08 ` Brian Hurt
2005-12-02 15:07 ` Michael D. Adams
2005-11-26 1:18 ` Jon Harrop
2005-11-27 14:57 ` Lukasz Stafiniak
2005-11-27 15:47 ` Lukasz Stafiniak
2005-11-28 8:14 ` Christophe Raffalli
2005-11-28 7:24 ` David Baelde
2005-11-28 7:49 ` Jacques Garrigue
2005-11-28 10:01 ` Jon Harrop
2005-11-28 10:26 ` Luc Maranget
2005-11-28 7:53 ` Ville-Pertti Keinonen
2005-12-01 17:05 ` Stefan Monnier
2005-12-02 15:07 ` [Caml-list] " Michael D. Adams
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=438A4CAA.6070006@univ-savoie.fr \
--to=raffalli@univ-savoie.fr \
--cc=bhurt@spnz.org \
--cc=caml-list@inria.fr \
/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