unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Neil Jerram <neil@ossau.uklinux.net>
To: ludo@gnu.org (Ludovic Courtès)
Cc: guile-devel@gnu.org
Subject: Re: array handles and non-local exits
Date: Sun, 19 Jul 2009 21:04:49 +0100	[thread overview]
Message-ID: <87ws64a17i.fsf@arudy.ossau.uklinux.net> (raw)
In-Reply-To: <874otkbv5j.fsf@gnu.org> ("Ludovic Courtès"'s message of "Fri\, 10 Jul 2009 14\:05\:28 +0200")

ludo@gnu.org (Ludovic Courtès) writes:

> Hey,
>
> Andy Wingo <wingo@pobox.com> writes:
>
> [...]
>
>> You can't just write functions that return values, you have to contort
>> code to store temporaries and then release and then return. You have
>> to write paired statements. If you call a user function, you really
>> should set up a dynwind, which conses, and contorts your code even
>> further.
>
> Right, that one has to set up a dynwind for nothing sucks.
>
>> Array_handle_release is a bad idea.
>
> Fair enough.

FWIW, I agree (I think with both of you) that `we might need it in
future' is not a good argument, but that API compatibility is.

> The doc would need to be revised (again).
>
> (It would have helped in this discussion if we knew the rationale for
> this API.  I couldn't find any trace of discussions around it.)

I'm pretty sure it was about allowing C code to efficiently access and
modify uniform vector contents, but at the same time supporting
operations which might require the underlying storage to be
reallocated.

The latter operations could include enlarging an existing vector, or
copy-on-write.  But AFAICT we never implemented either of those ideas,
and the existing code never changes the underlying storage of a
vector.

Regards,
        Neil




  reply	other threads:[~2009-07-19 20:04 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-15 20:17 array handles and non-local exits Neil Jerram
2008-09-16  7:56 ` Ludovic Courtès
2008-09-17 19:32   ` Neil Jerram
2008-09-18  8:15     ` Ludovic Courtès
2008-09-18  9:17       ` Neil Jerram
2008-09-18 13:44         ` Ludovic Courtès
2009-06-30 22:59           ` Neil Jerram
2009-07-01  8:37             ` Ludovic Courtès
2009-07-01 22:04               ` Neil Jerram
2009-07-01 22:36                 ` Ludovic Courtès
2009-07-02 23:33                   ` Neil Jerram
2009-07-03 23:38                     ` Neil Jerram
2009-07-04 19:28         ` Andy Wingo
2009-07-05 11:14           ` Ludovic Courtès
2009-07-06 14:09             ` Andy Wingo
2009-07-06 20:30               ` Ludovic Courtès
2009-07-09 19:19                 ` Andy Wingo
2009-07-09 21:08                   ` Ludovic Courtès
2009-07-10 10:27                     ` Andy Wingo
2009-07-10 12:05                       ` Ludovic Courtès
2009-07-19 20:04                         ` Neil Jerram [this message]
2009-07-20  9:20                           ` Ludovic Courtès
2009-07-23 21:20                             ` Andy Wingo

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=87ws64a17i.fsf@arudy.ossau.uklinux.net \
    --to=neil@ossau.uklinux.net \
    --cc=guile-devel@gnu.org \
    --cc=ludo@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).