From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: CPS Update Date: Tue, 19 Feb 2013 10:51:47 -0500 Message-ID: References: <871ucgrryo.fsf@tines.lan> <87txpcq7nx.fsf@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b338f1faf1f4204d615d1f1 X-Trace: ger.gmane.org 1361289130 25714 80.91.229.3 (19 Feb 2013 15:52:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Feb 2013 15:52:10 +0000 (UTC) Cc: guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Feb 19 16:52:29 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U7pUY-0008W6-V2 for guile-devel@m.gmane.org; Tue, 19 Feb 2013 16:52:27 +0100 Original-Received: from localhost ([::1]:60672 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7pUE-0001aK-Sy for guile-devel@m.gmane.org; Tue, 19 Feb 2013 10:52:06 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:59572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7pU3-0001Z5-D3 for guile-devel@gnu.org; Tue, 19 Feb 2013 10:52:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U7pTx-0003CU-E9 for guile-devel@gnu.org; Tue, 19 Feb 2013 10:51:55 -0500 Original-Received: from mail-pa0-f45.google.com ([209.85.220.45]:60392) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7pTx-0003Bg-3O for guile-devel@gnu.org; Tue, 19 Feb 2013 10:51:49 -0500 Original-Received: by mail-pa0-f45.google.com with SMTP id kl14so3489189pab.32 for ; Tue, 19 Feb 2013 07:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KpBCOm91990z0LQeCWGmjGLLjvkDCy9gbZxpNV0rUVU=; b=YgeOBlKIopiK7E6g6zwFsGnYIi6R2BpXdB+084VrwNGQ+sgFxKormFOh+2yoW1RUNX /9FJy6wKldMYPekTBLQF6Km9+r/zJRo17yvJEnUhOtKFCa2x8HFQtMYbq2r43dddfgpi gI9hxny0OQa9s579ra63Kca0Q2Xebyt9X41FegJaBmuXd/lUTPUZCrBXNQCYVNJnuxbU xr2M40tJjcsBAbE6IX73+lu/wRE+ru+jSaNWFGITT8xjxLZ/37GQw8hpKV2JUy8ezA84 MzoBphVJxrvxQIDqfextIBUBqbV73JKV/1iB77uoJhfdJACEdcK152IjPCII+QVu7EeZ qudQ== X-Received: by 10.68.237.165 with SMTP id vd5mr41452848pbc.52.1361289107414; Tue, 19 Feb 2013 07:51:47 -0800 (PST) Original-Received: by 10.68.157.42 with HTTP; Tue, 19 Feb 2013 07:51:47 -0800 (PST) In-Reply-To: <87txpcq7nx.fsf@tines.lan> X-Google-Sender-Auth: U9Vxr3kx6Cm9XNA4XFmZIjwEV10 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.220.45 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:15779 Archived-At: --047d7b338f1faf1f4204d615d1f1 Content-Type: text/plain; charset=ISO-8859-1 Hello, On Sat, Feb 16, 2013 at 4:18 PM, Mark H Weaver wrote: > Hi Noah, > > > On Sat, Feb 16, 2013 at 2:14 PM, Mark H Weaver wrote: > [...] > > Noah Lavine 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 --047d7b338f1faf1f4204d615d1f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

On Sat, Feb 16, 2013 at 4:18 PM, Mark H Weaver <= mhw@netris.org><= /span> wrote:
Hi Noah,

> On Sat, Feb 16, 2013 at 2:14 PM, Mark H Weaver <mhw@netris.org> wrote:
[...]
> =A0 =A0 Noah Lavine <noah.b.lavine@gmail.com> writes:
>
> You mean if a function modifies another function that called it.

There are many other cases. =A0Think multiple threads, coroutines, lo= gic
programming systems, etc. =A0That's why I wrote "stack(s)". = =A0Actually, I
should have written "(partial) continuation(s)". =A0There are any= number
of ways that an activation record for some procedure you modify could
still be alive somewhere in the heap. =A0The issue can arise even with
simple lazy data structures. =A0I don't think it's something we sho= uld
punt on. =A0IMO anyway.

What do you think?

Yes, you're righ= t. I hadn't thought about those cases. This is a tricky question.
=

But before we continue, are you sure that the right sem= antics is to modify all of the continuations? In particular, let's say = you have a function like this:

(define (func x)
=A0 (+ x 2 (my-s= pecial-function x)))

And my-special-fu= nction captures its continuation, k. Later on, you modify func to be this:<= /div>

(define (func x)
=A0 (+ x 2= ))

Now what is the continuation k supp= osed to do? That continuation doesn't exist in the latest version of fu= nc. 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, b= ut 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 wh= at 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

--047d7b338f1faf1f4204d615d1f1--