From: nisse@lysator.liu.se (Niels Möller)
To: guile-user@gnu.org
Subject: Question on mutability of argument lists
Date: Wed, 19 Mar 2014 10:34:43 +0100 [thread overview]
Message-ID: <nnr45yy1jg.fsf@bacon.lysator.liu.se> (raw)
Hi,
I discovered r7rs thanks to the recent guile release announcement. I
have one question (which likely applies also to earlier revisions). Not
sure what the right forum is, but I hope some of the guile people are
familiar with these things and if maybe even can push for some
clarification of the spec if needed. I tried mailing to
scheme-reports-owner@scheme-reports.org, but that list seems to be
member's only).
When specifying the use of rest arguments for procedures (r7rs, sec
4.1.4), it seems to imply that the passed argument list is mutable? This
is convenient in some ways, e.g., I think the following definition of
the list procedure should be correct
(define (list . args) args)
However, for a natural implementation which evaluates arguments and
conses the results up to a list, this seems to require an extra copy of
the argument list, after all values are evaluated and before the list is
bound to the rest parameter. To see why, assume that evaluation of one
of the arguments captures its continuation and returns several times. If
this isn't the first argument evaluated, without the extra copying, one
gets several calls to the procedure with the rest argument sharing
structure, and if the shared part is mutated, things go bad. And since
I'd expect that the vast majority of function calls with rest arguments
to *not* need any mutability of the argument list, this extra copying
seems like an undesirable overhead.
On the other hand, if the argument is specified as immutable, then no
copying is needed in the common case (as far as I understand, consing up
the evaluated arguments will give the correct results no matter how many
times the evaluation of a particular argument returns), but instead, the
implementation of procedures like list must explicitly construct a
new mutable copy of the argument list.
It's not obvious if the general description "All objects created by the
other procedures listed in this report are mutable." (sec 3.4) applies
to the constructed argument lists, so if argument lists for rest
parameters really are intended to be mutable, then I think that could be
made clearer.
I guess the formal semantics section ought to answer the question on
whether or not one can get shared structure in argument lists in case
evaluation of an argument returns multiple times, but I haven't tried to
figure that out...
Regards,
/Niels Möller
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
next reply other threads:[~2014-03-19 9:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-19 9:34 Niels Möller [this message]
2014-03-19 17:01 ` Question on mutability of argument lists Marco Maggi
2014-03-19 19:25 ` Mark H Weaver
2014-03-19 19:56 ` Niels Möller
2014-03-20 10:06 ` [OT] " Marco Maggi
2014-03-20 10:54 ` Niels Möller
2014-03-20 21:02 ` 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=nnr45yy1jg.fsf@bacon.lysator.liu.se \
--to=nisse@lysator.liu.se \
--cc=guile-user@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).