unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Krister Svanlund <krister.svanlund@gmail.com>
To: David Kastrup <dak@gnu.org>
Cc: guile-devel@gnu.org
Subject: Re: Growable arrays?
Date: Sat, 9 Jun 2012 16:43:27 +0200	[thread overview]
Message-ID: <CAO_vGe8VTs589u9Ei42utuAqBrSGqUg9dgJSZ=JgeYcAwy3w3w@mail.gmail.com> (raw)
In-Reply-To: <87hauku0mb.fsf@fencepost.gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2500 bytes --]

On Sat, Jun 9, 2012 at 2:32 PM, David Kastrup <dak@gnu.org> wrote:

>
> Hi,
>
> the main data structure of Lua is a "table", an associative array, and a
> table t has a continguous numerically addressed part from 1..#t, with
> all other indices going through a hashing mechanism.  One principal
> distinguishing feature, like with a Scheme hashtable, is the ability to
> grow on-demand.
>
> Scheme/Guile vectors are fixed size.  Now I have a situation where I
> have a basic type lattice with records stored in vectors, and this type
> lattice may be extended dynamically (which typically happens at the
> start of a whole file, for potentially multi-file runs).  Scheme does
> not offer a suitable data structure for that.  It is a bit of a nuisance
> that one can grow a hashtable efficiently and on-demand, but not so an
> array.
>
> Now it would be possible when the type lattice gets extended to store
> the new entries in a hashtable and go from there.  Or put them into a
> list, and reallocate on first access beyond the existing element.  That
> seems rather contorted.  And since there is, if I remember, a project to
> run Lua on top of Guile, having a fundamental and reasonably efficient
> data structure corresponding to a Lua table, or at least the contiguous
> part of a Lua table, would seem like a reasonably useful idea.  After
> all, there already _is_ such a mechanism underlying hash tables so it
> seems somewhat peculiar not to have it available for vectors as well.
>
> Suggestions?
>
> --
> David Kastrup
>
>
>
I don't know how much you know about data structures, and I must confess
I'm not very educated on Guile or Luas implementations. Based on what you
are writing I would assume that the scheme hashtables aren't growable in
the same way as a vector has to be growable. The number of elements in a
hashtable isn't limited by it's "size". They are often implemented as each
position (where the hashtables size is the number of positions) being a
linked list giving the hashtable (in theory) limitless actual size. Growing
a vector/array involves having to allocate new continuous memory and
copying all the elements there, so for example in C++ (i think) the
std:vector is increased by half it's current size each time meaning that
the more expensive the copying gets the more elements you can insert into
the vector before it has to resize.

I would assume it wouldn't be that difficult to implement a pretty
efficient growable vector for scheme.

// Krister Svanlund

[-- Attachment #2: Type: text/html, Size: 2970 bytes --]

  reply	other threads:[~2012-06-09 14:43 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-09 12:32 Growable arrays? David Kastrup
2012-06-09 14:43 ` Krister Svanlund [this message]
2012-06-09 17:35   ` David Kastrup
2012-06-11  4:23 ` Daniel Hartwig
2012-06-11  4:37   ` David Kastrup
2012-06-11  5:00     ` Daniel Hartwig
2012-06-11  7:25       ` David Kastrup
2012-06-11  9:01         ` Daniel Hartwig
2012-06-11  9:13           ` Daniel Hartwig
2012-06-11 10:38             ` David Kastrup
2012-06-11 11:57               ` Daniel Hartwig
2012-06-11 12:13         ` Noah Lavine
2012-06-11 12:28           ` David Kastrup
2012-06-11 23:50             ` Mark H Weaver
2012-06-12  9:34               ` David Kastrup
2012-06-12 20:34                 ` Mark H Weaver
2012-06-12 20:47                   ` David Kastrup
2012-06-12 21:03                     ` Mark H Weaver
2012-06-12 21:18                       ` David Kastrup
2012-06-11  8:14 ` Thien-Thi Nguyen
2012-06-11  9:08 ` Andy Wingo
2012-06-11  9:55   ` David Kastrup
2012-06-11 11:25     ` Andy Wingo
2012-06-11 12:00       ` David Kastrup
2012-06-11 12:12         ` David Kastrup
2012-06-11 12:20           ` David Kastrup
2012-06-11 13:04             ` Daniel Hartwig
2012-06-11 14:19               ` David Kastrup
2012-06-11 15:24                 ` Stefan Israelsson Tampe
2012-06-11 15:27                 ` Andy Wingo
2012-06-11 16:03                   ` David Kastrup
2012-06-11 12:20         ` Daniel Hartwig
2012-06-11 12:36           ` David Kastrup
2012-06-11 12:02 ` Ludovic Courtès
2012-06-12 13:36 ` Hans Aberg
2012-06-14 14:33 ` Mark H Weaver
2012-06-14 14:47   ` David Kastrup
2012-06-14 15:23     ` Daniel Hartwig
2012-06-14 15:34       ` David Kastrup
2012-06-14 16:56         ` Daniel Hartwig
2012-06-14 17:15           ` David Kastrup
2012-06-14 17:23             ` Daniel Hartwig
2012-06-14 17:49               ` David Kastrup

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

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAO_vGe8VTs589u9Ei42utuAqBrSGqUg9dgJSZ=JgeYcAwy3w3w@mail.gmail.com' \
    --to=krister.svanlund@gmail.com \
    --cc=dak@gnu.org \
    --cc=guile-devel@gnu.org \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).