Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Markus Mottl <markus@oefai.at>
To: Winfried Dreckmann <wd@lidingo.mail.telia.com>
Cc: OCAML <caml-list@inria.fr>
Subject: Re: [Caml-list] local root registration
Date: Fri, 22 Feb 2002 15:27:41 +0100	[thread overview]
Message-ID: <20020222142741.GA22329@chopin.ai.univie.ac.at> (raw)
In-Reply-To: <B89BF2C8.AE14%wd@lidingo.mail.telia.com>

On Fri, 22 Feb 2002, Winfried Dreckmann wrote:
> 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.

Yes, to me they also seem more approriate at times.

> I will discuss this a little. Perhaps the Begin_roots/End_roots macros
> should not be deprecated, but left as a low level alternative?

I can't remember that there were intentions to remove them. They rather
seem to be discouraged in favour of the new scheme whenever the latter
can be applied without tradeoffs.

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

There should certainly be an efficient way to conditionally protect
roots, which cannot be done with the new macro scheme. Furthermore,
to my knowledge there is currently no way to allocate and raise more
complex exceptions with "mlraise" without using the older macros.

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

If I am not seriously mistaken, only allocations on the OCaml-heap can
trigger a collection. There is just a small overhead associated with
(un)registering OCaml-values as reachable, but it's certainly a good idea
to remove every kind of unnecessary overhead in performance-critical code.

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
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 14:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-22 12:06 Winfried Dreckmann
2002-02-22 14:27 ` Markus Mottl [this message]
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=20020222142741.GA22329@chopin.ai.univie.ac.at \
    --to=markus@oefai.at \
    --cc=caml-list@inria.fr \
    --cc=wd@lidingo.mail.telia.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