From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
To: caml-list@inria.fr
Subject: Re: practical functional programming
Date: 7 Nov 2000 19:19:40 GMT [thread overview]
Message-ID: <slrn90gleb.jek.qrczak@qrnik.knm.org.pl> (raw)
In-Reply-To: <4.3.2.7.2.20001106100700.00c447b0@shell16.ba.best.com>
Mon, 06 Nov 2000 10:15:30 -0800, Chris Hecker <checker@d6.com> pisze:
> I guess my next question then would be related to efficiency:
> isn't there a lot of copying going on if you've got to make a new
> instance of your symbol table just to add an element? How does
> this work out in practice?
It depends on how the symbol table is implemented.
With balanced binary trees element search costs log(N) and obtaining
an updated mapping costs log(N). Updating must copy the path from
the root to the place where the change is being made.
With hash tables search costs a constant time but obtaining an updated
mapping costs N.
There is a tricky idea providing fast arrays with a functional
interface. A mutable array is kept under a mutable reference.
Obtaining an updated array does the update in place and then replaces
the contents of the old reference by a data structure which refers
to the new copy and tells which element to replace by which old
value. So values from which other versions were derived behave as
before, even though their representation changes. Accessing older
versions becomes slower and slower as more updates are being made.
There is a complex imperative implementation here, especially as we
must deal with cases when the updated version is no longer used and
there is a chain of updates starting from an older copy. When versions
diverge too much, probably it's time to make separate copies. I'm
not sure how all details should be done. But once it is done, usage
of these arrays is completely functional.
> Is there some sort of reference counted sharing going on, or are
> there actually two copies of the data in memory if you wrote your
> example in caml?
Everything not explicitly copied is shared, but OCaml's implementation
of the garbage collector does not use reference counting.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
next prev parent reply other threads:[~2000-11-08 17:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-03 22:44 Chris Hecker
2000-11-04 18:48 ` Chet Murthy
2000-11-05 14:25 ` John Max Skaller
2000-11-06 22:26 ` Michael Hicks
2000-11-06 6:55 ` Francisco Reyes
2000-11-06 13:16 ` Jean-Christophe Filliatre
2000-11-06 18:15 ` Chris Hecker
2000-11-07 7:54 ` Stephan Houben
2000-11-11 14:32 ` John Max Skaller
2000-11-12 13:17 ` Ken Wakita
2000-11-12 20:09 ` John Max Skaller
2000-11-13 0:19 ` Ken Wakita
2000-11-13 7:45 ` STARYNKEVITCH Basile
2000-11-07 9:06 ` Xavier Leroy
2000-11-07 10:13 ` Chris Hecker
2000-11-09 10:56 ` Stephan Houben
2000-11-09 21:56 ` Chris Hecker
2000-11-07 18:05 ` Thorsten Ohl
2000-11-07 19:19 ` Marcin 'Qrczak' Kowalczyk [this message]
2000-11-06 23:10 Hao-yang Wang
2000-11-06 23:24 Hao-yang Wang
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=slrn90gleb.jek.qrczak@qrnik.knm.org.pl \
--to=qrczak@knm.org.pl \
--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