From: Noah Lavine <noah.b.lavine@gmail.com>
To: Mark H Weaver <mhw@netris.org>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: CPS Update
Date: Tue, 19 Feb 2013 10:51:47 -0500 [thread overview]
Message-ID: <CA+U71=POy-eKqjSvrH39ohQfqr3r5PhQ1J5FpUymcekJAVh+ng@mail.gmail.com> (raw)
In-Reply-To: <87txpcq7nx.fsf@tines.lan>
[-- Attachment #1: Type: text/plain, Size: 1899 bytes --]
Hello,
On Sat, Feb 16, 2013 at 4:18 PM, Mark H Weaver <mhw@netris.org> wrote:
> Hi Noah,
>
> > On Sat, Feb 16, 2013 at 2:14 PM, Mark H Weaver <mhw@netris.org> wrote:
> [...]
> > Noah Lavine <noah.b.lavine@gmail.com> writes:
> >
> > You mean if a function modifies another function that called it.
>
> There are many other cases. Think multiple threads, coroutines, logic
> programming systems, etc. That's why I wrote "stack(s)". Actually, I
> should have written "(partial) continuation(s)". There are any number
> of ways that an activation record for some procedure you modify could
> still be alive somewhere in the heap. The issue can arise even with
> simple lazy data structures. I don't think it's something we should
> punt on. IMO anyway.
>
> What do you think?
>
Yes, you're right. I hadn't thought about those cases. This is a tricky
question.
But before we continue, are you sure that the right semantics is to modify
all of the continuations? In particular, let's say you have a function like
this:
(define (func x)
(+ x 2 (my-special-function x)))
And my-special-function captures its continuation, k. Later on, you modify
func to be this:
(define (func x)
(+ x 2))
Now what is the continuation k supposed to do? That continuation doesn't
exist in the latest version of func. I think in this case you have to treat
it like a closure that is still holding on to the continuation that it was
passed (conceptually, at least) when it was called. So it would return to
the old version of func.
On the other hand, take the same example, but this time redefine "+"
instead of "func". Now, does the continuation k call the new definition of
+, or the old one?
These really are questions for me. I don't know what the correct behavior
here is, but I think that if we can answer both of these questions, then we
know more or less what the correct thing to do is.
Noah
[-- Attachment #2: Type: text/html, Size: 2811 bytes --]
next prev parent reply other threads:[~2013-02-19 15:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-16 0:53 CPS Update Noah Lavine
2013-02-16 7:39 ` Stefan Israelsson Tampe
2013-02-16 16:29 ` Noah Lavine
2013-02-16 19:14 ` Mark H Weaver
2013-02-16 19:36 ` Noah Lavine
2013-02-16 21:18 ` Mark H Weaver
2013-02-19 15:51 ` Noah Lavine [this message]
2013-02-19 16:21 ` Mark H Weaver
2013-02-22 8:25 ` William ML Leslie
2013-02-23 7:49 ` Mark H Weaver
2013-02-25 4:54 ` William ML Leslie
2013-02-26 10:24 ` Mark H Weaver
2013-02-19 17:29 ` Stefan Israelsson Tampe
2013-03-08 22:57 ` Noah Lavine
2013-03-09 8:31 ` Andy Wingo
2013-04-03 20:50 ` Noah Lavine
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='CA+U71=POy-eKqjSvrH39ohQfqr3r5PhQ1J5FpUymcekJAVh+ng@mail.gmail.com' \
--to=noah.b.lavine@gmail.com \
--cc=guile-devel@gnu.org \
--cc=mhw@netris.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).