From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Israelsson Tampe Newsgroups: gmane.lisp.guile.devel Subject: Re: Special variables to relax boxing Date: Thu, 21 Mar 2013 21:15:44 +0100 Message-ID: <12515493.61rmnodEK6@warperdoze> References: <3101921.Ei70kTLzB2@warperdoze> <87d2usa845.fsf@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Trace: ger.gmane.org 1363896958 364 80.91.229.3 (21 Mar 2013 20:15:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Mar 2013 20:15:58 +0000 (UTC) Cc: guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Mar 21 21:16:24 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 1UIluR-0007o7-En for guile-devel@m.gmane.org; Thu, 21 Mar 2013 21:16:23 +0100 Original-Received: from localhost ([::1]:43373 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIlu3-0000FG-Si for guile-devel@m.gmane.org; Thu, 21 Mar 2013 16:15:59 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIltz-0000Eu-Ky for guile-devel@gnu.org; Thu, 21 Mar 2013 16:15:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIltv-0007Ly-3z for guile-devel@gnu.org; Thu, 21 Mar 2013 16:15:55 -0400 Original-Received: from mail-la0-x229.google.com ([2a00:1450:4010:c03::229]:65019) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIltu-0007KL-Rd for guile-devel@gnu.org; Thu, 21 Mar 2013 16:15:51 -0400 Original-Received: by mail-la0-f41.google.com with SMTP id fo12so5996268lab.14 for ; Thu, 21 Mar 2013 13:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=Oc56HE0emMB13wCWT/7jdIUJL+fZ7gbTqpU1SAHhvRI=; b=zteGyv+ARo0CA4JtiLeXUDta1UVje2wA5cT2rsm0Ul3xVcR00McNFHK5ShZQjCcTkW MJ2gQoNDRzB5YZgdwQULixiikf+8QcD1L00LoUMuw5fsA7Z7pE9y2CKg2tt/N2LepIAI EAOUZ36thH9P/X7mm8C1LYsRYvgEnU1q6fq5TI9HETKJAc+fNpRblYVeFFknxYd9ip00 JJIoKvxhZp9ek03Ivrp8SQsUwpUZMFiXMJJEJh+iv39+9xAVltqbGYWU40gjtdj/9RqZ oBGCupognkBDqnkTR+15U+z3pi0DlLAwA9HFFwNltbR1d1e0wL93o05hYGM2sSI0jgxt obnQ== X-Received: by 10.152.144.202 with SMTP id so10mr8490761lab.9.1363896949758; Thu, 21 Mar 2013 13:15:49 -0700 (PDT) Original-Received: from warperdoze.localnet (1-1-1-39a.veo.vs.bostream.se. [82.182.254.46]) by mx.google.com with ESMTPS id v7sm2544570lbg.13.2013.03.21.13.15.47 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Mar 2013 13:15:48 -0700 (PDT) User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; x86_64; ; ) In-Reply-To: <87d2usa845.fsf@tines.lan> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::229 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:15961 Archived-At: On Thursday, March 21, 2013 03:03:06 PM Mark H Weaver wrote: > Stefan, you're still describing your proposal in terms of low-level > implementation details such as stacks. In the general case, we cannot > store environment structures on the stack. Furthermore, in the > general case *all* variables in scheme are bound to locations, not > values. Only in special cases can we use stacks, and only in special > cases can we avoid boxing variables. These are only _optimizations_. > > If you're serious about this proposal, please read sections 3.1 and > 3.4 of the R5RS carefully. Explain your proposed _semantics_ (not > the implementation details) in those terms, where *all* variables are > bound to _locations_, and where there is no stack at all (everything > is conceptually stored in a garbage-collected heap). > > We need to understand the *semantics* in the simplest possible terms > before we even begin to think about how to implement it. > > Thanks, > Mark Ok, the sematics for the simple version is are, Assume k, the continuation associated with with a dynamic wind or unwind assume that there is a map from each continuation (k,id) to a value and getting and setting of this value is done through ref-get and ref-set, assume that the winder and the rewinder lambda takes a first argument k beeing the continuation under action, finally make-id will make a unique object. then the semantic would be: (define-syntax-rule (with-special (a) code) (let ((id (make-id))) (dynamic-wind (lambda (k) (set! a (ref-get k id))) (lambda () code) (lambda (k) (ref-set! k id a))))) A possible refinment of this is associate to k two predicates e.g. (do-wind? k kind) predicate and a (do-unwind? k kind) wich takes a parameter kind, then use the semanics (define-syntax-rule (with-special (a kind) code) (let ((id (make-id))) (dynamic-wind (lambda (k) (when (do-wind? k kind) (set! a (ref-get k id)))) (lambda () code) (lambda (k) (when (do-unwind? k kind) (ref-set! k id a)))))) Hopes this helps! /Stefan