Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Winfried Dreckmann <wd@lidingo.mail.telia.com>
To: "€ caml list" <caml-list@inria.fr>
Subject: [Caml-list] local root registration
Date: Fri, 22 Feb 2002 13:06:16 +0100	[thread overview]
Message-ID: <B89BF2C8.AE14%wd@lidingo.mail.telia.com> (raw)

Dear Caml-list,

Some time ago, Xavier Leroy wrote:

> We've been through several designs for the "local root registration" API.
> The CAMLxxx macros are the latest design, and the one that we think is
> the easiest to use.

I agree that they are easiest if one strictly follows the rules in the
documentation. However, I would like to point out that there are cases where
one does not want to do this. In these cases, the older macros (Begin_roots
and End_roots) are much more flexible, and can even lead to better code.

I will discuss this a little. Perhaps the Begin_roots/End_roots macros
should not be deprecated, but left as a low level alternative? In one case
the documentation already differs between a simple and a low level
interface, and I believe this is a good approach. What do other list members
think?

I am thinking of cases, where one uses resizable blocks, which are only
occasionally resized, while usually nothing gets allocated. A good example
is Michel Quercia's "Numerix". He has resizable big integers, and of course
wants to save every cpu cycle for crucial arithmetic operations when
allocation does not occur. His approach is to surround the allocators and
resizers by Begin_roots/End_roots macros, e. g.

#define Enlarge_1_1(a,l,b) {             \
  if (Capacity(a) < (l)) {               \
    Begin_roots2(a,b);                   \
    New(a,0,2*(l)+1);                    \
    End_roots2(a,b);                     \
  }                                      \
}

(see "lib/common/ml-alloc.h" in the numerix distribution). In this way, the
price for garbage collection is only paid if allocation actually takes
place. It seems impossible to achieve the same effect with CAMLxxx macros.

Winfried Dreckmann

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


             reply	other threads:[~2002-02-22 12:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-22 12:06 Winfried Dreckmann [this message]
2002-02-22 14:27 ` Markus Mottl
2002-02-22 18:10   ` Winfried Dreckmann
2002-02-24 17:28 ` Xavier Leroy
2002-02-24 17:58 ` Michel Quercia

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=B89BF2C8.AE14%wd@lidingo.mail.telia.com \
    --to=wd@lidingo.mail.telia.com \
    --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