caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Diego Olivier Fernandez Pons <Diego.FERNANDEZ_PONS@etu.upmc.fr>
To: caml-list@inria.fr
Subject: Do I need an array of untyped pointers ?
Date: Tue, 8 Feb 2005 12:10:03 +0100 (NFT)	[thread overview]
Message-ID: <Pine.A41.4.44.0502081142420.1097814-100000@ibm1> (raw)

    Bonjour,

I have a backtracking program that uses data structure persistence to
keep track of all alive branches of the enumeration tree

f : 'a set -> 'a set -> 'a is a recursive function

  f a b  --> f (add x a) b --> ...
         --> f a (add x b) --> ...

There is an example for the subsetsum problem in comp.lang.functional (Backtracking in Haskell ?)
http://groups.google.fr/groups?hl=fr&lr=&selm=6443cc98.0407190449.58f31cc8%40posting.google.com

The backtracking is done as usual raising an exception and recovering
the previous state (here is where data persistence is useful)

I want to expand my program in order to accept an unspecified number
of arguments of heterogeneous types [in other words I want a 'generic'
function f in the sense that you do not have to write it again for
every specific problem]

There are two problems :
- variable number of arguments
- arguments of different type (set, map, ...)

There is a well known trick (used e.g in FaCiLe by Pascal Brisset and
Nicolas Barnier) which consists basically on making all operations
have the same 'type' (unit -> unit) and saving them all in a
persistent data structure (list type)

Then you have a 'single' data structure and you do/undo modifications
when you go up/down the enumeration tree.

(from FaCiLe 1.1 fcl_stak.ml)

let backtrack_all () =
  let rec bt = function
      Level {failure=s} -> bt s
    | Empty -> reset ()
    | Trail (undo, s) -> undo (); bt s in
  bt !stack

The problem is that I don't see the point in letting the garbage
collector sweep the 'previous' data structure and build it back some
time after when you only had to hold it (keeping it alive with a
pointer).

I went to the conclusion that what I seemed to need was a kind of
'untyped array of pointers' which is in a sense what the compiler uses
when one writes

   f a b c d ...

Any suggestion on how to workaround ?


        Diego Olivier



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

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=Pine.A41.4.44.0502081142420.1097814-100000@ibm1 \
    --to=diego.fernandez_pons@etu.upmc.fr \
    --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;
as well as URLs for NNTP newsgroup(s).