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: redo-safe-variables and redo-safe-parameters Date: Tue, 26 Mar 2013 17:07:13 -0400 Message-ID: References: <13378334.Jv25yq6OaM@warperdoze> <4099741.BPvjEG9t1k@warperdoze> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bd7646e6c6a9404d8da4f44 X-Trace: ger.gmane.org 1364332062 28472 80.91.229.3 (26 Mar 2013 21:07:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Mar 2013 21:07:42 +0000 (UTC) Cc: guile-devel To: Stefan Israelsson Tampe Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Mar 26 22:08:06 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 1UKb6C-0004F2-QI for guile-devel@m.gmane.org; Tue, 26 Mar 2013 22:08:05 +0100 Original-Received: from localhost ([::1]:33102 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKb5o-0003Et-Lg for guile-devel@m.gmane.org; Tue, 26 Mar 2013 17:07:40 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42639) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKb5l-0003Ee-4z for guile-devel@gnu.org; Tue, 26 Mar 2013 17:07:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKb5j-0006W6-2N for guile-devel@gnu.org; Tue, 26 Mar 2013 17:07:37 -0400 Original-Received: from mail-pa0-f44.google.com ([209.85.220.44]:51995) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKb5i-0006Vy-OB for guile-devel@gnu.org; Tue, 26 Mar 2013 17:07:34 -0400 Original-Received: by mail-pa0-f44.google.com with SMTP id bi5so1825655pad.3 for ; Tue, 26 Mar 2013 14:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=mty6GsU7Ha/IXf3K4jjaR9NwpkOk7zGs2xoGx5eWAbY=; b=w7j/hhrG7ISoxPRFkhFP1CgDYcEFb8L2kZxq/j2LhvZldMe9VIMG97c7XNpuyBss6e xGo4/gPEKuAu7pPQPUPFukKUQhzhle73qMEJwGFfIiMGPXzrXp2hT4WoJgOxzFXZnPlM dnI1J3zj5mNF2fZvZWyP8EUQAgNJmhKS//AIQr9tdpOapEHmIrVIB7R0+rZxcqgtfg4x e5ec80SRvBzqGqIaK6YpzRiryouon/2KfxoxLouKovNq9/fxEmdgsVK281TRhzddf/Fe RRG0MtPdLNmTYqLY+2PVQu6Oz5S5zDgHoK719CJ6Y0HhxxQs0rmbDtpFwBCqXjoBxCmD f3ig== X-Received: by 10.68.184.33 with SMTP id er1mr25977119pbc.151.1364332053815; Tue, 26 Mar 2013 14:07:33 -0700 (PDT) Original-Received: by 10.68.157.42 with HTTP; Tue, 26 Mar 2013 14:07:13 -0700 (PDT) In-Reply-To: <4099741.BPvjEG9t1k@warperdoze> X-Google-Sender-Auth: aUxTpv_nv4NpvK3Pl0mPIbk16Gk X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.220.44 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:16004 Archived-At: --047d7bd7646e6c6a9404d8da4f44 Content-Type: text/plain; charset=ISO-8859-1 Yes, I think parameters and fluids are the same. I was wondering if (with-redo-variables ...) could be a macro that expands to (with-fluids ...). Is that possible? It might not be. Yeah, I had forgotten about the closure variables issue. That might turn out to be a big problem with all of this, but we'll see. Noah On Tue, Mar 26, 2013 at 4:43 PM, Stefan Israelsson Tampe < stefan.itampe@gmail.com> wrote: > Relly kind of you to answer this quickly, > good thoughts! > On Tuesday, March 26, 2013 02:05:41 PM Noah Lavine wrote: > > Hello, > > > > Two quick thoughts on this: > > > > 1. It's confusing to say "undo" and "redo", because those aren't in > > the Scheme standard, and I don't know of any SRFIs that have them > > either. Instead, maybe you could say "using continuations to > > implement computations that restart". Or, "using continuations to > > implement backtracking in a logic program" (if that's how guile-log > > does it). > Good point, I will define the wording. > > > > 2. Can you say more about how you would implement them with parameters > > and why that's not good enough? Maybe you could show equivalent code > > snippets using parameters and your proposed form. > parameters, and fluids are they not the basically the same? just a > different interface? with parameters more flexible and fluids more > optimized although parameters can be inlined many times? > > > > 2a. If parameters work but are annoying to use, how about fluids? > > Guile and a few other Schemes implement them. Maybe this could be a > > justification for making fluids into a SRFI, instead of introducing a > > new interface. > I took them for basically the same concept. I just saw a srfi for > parameters thought I should use them instead. I will try read the spec > for fluids and parameters again. > > > 3. Points number 8 and 11 have no text at all, just code. It's not > > clear what they mean. > I will add text to this, good point. > > > 4. In general, I think this proposal is too low-level. You shouldn't > > require people to implement it in a certain way; you just want to > > convince them that it's *possible* to implement this reasonably. > > Please note that that in the semantics I mention for example integer > numbers just to be precise. I do not expect people to use the code > exactly as I write it. I do expect the implementors to optimize away > quite a lot of what the spec describes e.g. I'm not describing a macro > I'm describing an algorithm in for that case I believe to be pretty > exact. The tail call properties is quite important for practiaclly be > able to share logic programming using this srfi without it I fear that > portability will only be on paper. > > > Overall, I think I would organize this into three sections: > > > > I. Examples showing the need for a new type of variable. > > II. An exact specification of the semantics of these variables. I > > gave a partial specification by rewriting special variables as > > lexicals and using continuation-passing style in a previous email. I > > think that would give the semantics that you want, and I can help > > with that if you'd like. III. An example implementation. This doesn't > > have to be the implementation that would really be used; it just > > needs to be enough to show that it is possible to implement this in a > > reasonable way. > > Good idea. btw I do have a implementation already that I can copy > in. But not all logic can be coded without actually changing the > compiler. > > Also I would add a discussion about optimisations to show that one > would gain in speed and e.g. show that the argument for speed > improvement is sound. Finally a discussion about ease of > implementation could be good to show that we can get far by > piggypacking on current technology and what things in the spec might > cause the most trubble e.g. the dynamic condition that guarantees > tail call property. > > I have an issue with continuation passing style and you point it out > as well in your email. Special variables placed in a lambda would > cause trouble with this approach and not only this I would like to try > let the construct guard toplevel variables as well and hence these > (horably) could change when someone reinstates a continuation. I do > see the beuty of your approach and it describes and important > optimisation that quite ofthen will apply, actually there is bloat > using the guard and if you litter the code with guarding yoe relly > want this type of behavior most of the time. > > Thanks > Stefan > > --047d7bd7646e6c6a9404d8da4f44 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, I think parameters and fluids are the same. I wa= s wondering if (with-redo-variables ...) could be a macro that expands to (= with-fluids ...). Is that possible? It might not be.

Yeah, I h= ad forgotten about the closure variables issue. That might turn out to be a= big problem with all of this, but we'll see.

Noah


On Tue, Mar 26, 2013 at 4:43 PM, Stefan Israelsson Tampe <stefa= n.itampe@gmail.com> wrote:
Relly kind of you to answer this quickly, good thoughts!
On Tuesday, March 26, 2013 02:05:41 PM Noah Lavine wrote:=
> Hello,
>
> Two quick thoughts on this:
>
> 1. It's confusing to say "undo" and "redo", be= cause those aren't in
> the Scheme standard, and I don't know of any SRFIs that have them<= br> > either. Instead, maybe you could say "using continuations to
> implement computations that restart". Or, "using continuatio= ns to
> implement backtracking in a logic program" (if that's how gui= le-log
> does it).
Good point, I will define the wording.


> 2. Can you say more about how you would implement them with parameters=
> and why that's not good enough? Maybe you could show equivalent co= de
> snippets using parameters and your proposed form.
parameters, and fluids are they not the basically the same? just a different interface? with parameters more flexible and fluids more
optimized although parameters can be inlined many times?


> 2a. If parameters work but are annoying to use, how about fluids?
> Guile and a few other Schemes implement them. Maybe this could be a > justification for making fluids into a SRFI, instead of introducing a<= br> > new interface.
I took them for basically the same concept. I just saw a srfi for
parameters thought I should use them instead. I will try read the spec
for fluids and parameters again.

> 3. Points number 8 and 11 have no text at all, just code. It's not=
> clear what they mean.
I will add text to this, good point.

> 4. In general, I think this proposal is too low-level. You shouldn'= ;t
> require people to implement it in a certain way; you just want to
> convince them that it's *possible* to implement this reasonably.
Please note that that in the semantics I mention for example integer<= br> numbers just to be precise. I do not expect people to use the code
exactly as I write it. I do expect the implementors to optimize away
quite a lot of what the spec describes e.g. I'm not describing a macro<= br> I'm describing an algorithm in for that case I believe to be pretty
exact. The tail call properties is quite important for practiaclly be
able to share logic programming using this srfi without it I fear that
portability will only be on paper.

> Overall, I think I would organize this into three sections:
>
> =A0 I. Examples showing the need for a new type of variable.
> =A0 II. An exact specification of the semantics of these variables. I<= br> > gave a partial specification by rewriting special variables as
> lexicals and using continuation-passing style in a previous email. I > think that would give the semantics that you want, and I can help
> with that if you'd like. III. An example implementation. This does= n't
> have to be the implementation that would really be used; it just
> needs to be enough to show that it is possible to implement this in a<= br> > reasonable way.

Good idea. btw I do have a implementation already that I can copy
in. But not all logic can be coded without actually changing the
compiler.

Also I would add a discussion about optimisations to show that one
would gain in speed and e.g. show that the argument for speed
improvement is sound. Finally a discussion about ease of
implementation could be good to show that we can get far by
piggypacking on current technology and what things in the spec might
cause the most trubble e.g. the dynamic condition that guarantees
tail call property.

I have an issue with continuation passing style and you point it out
as well in your email. Special variables placed in a lambda would
cause trouble with this approach and not only this I would like to try
let the construct guard toplevel variables as well and hence these
(horably) could change when someone reinstates a continuation. I do
see the beuty of your approach and it describes and important
optimisation that quite ofthen will apply, actually there is bloat
using the guard and if you litter the code with guarding yoe relly
want this type of behavior most of the time.

Thanks
Stefan


--047d7bd7646e6c6a9404d8da4f44--