From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Glenn Michaels" Newsgroups: gmane.lisp.guile.bugs Subject: bug#24102: Use guile variable objects as SRFI-111 boxes. Date: Thu, 18 Aug 2016 09:07:26 -0400 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1471525703 23787 195.159.176.226 (18 Aug 2016 13:08:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 18 Aug 2016 13:08:23 +0000 (UTC) Cc: 24102@debbugs.gnu.org To: mhw@netris.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Thu Aug 18 15:08:19 2016 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1baN3S-0005t7-98 for guile-bugs@m.gmane.org; Thu, 18 Aug 2016 15:08:18 +0200 Original-Received: from localhost ([::1]:52628 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1baN3P-0004x3-Pp for guile-bugs@m.gmane.org; Thu, 18 Aug 2016 09:08:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35570) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1baN3I-0004vd-7m for bug-guile@gnu.org; Thu, 18 Aug 2016 09:08:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1baN3C-0001zt-7m for bug-guile@gnu.org; Thu, 18 Aug 2016 09:08:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35047) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1baN3C-0001zn-3X for bug-guile@gnu.org; Thu, 18 Aug 2016 09:08:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1baN3B-0001il-Og for bug-guile@gnu.org; Thu, 18 Aug 2016 09:08:01 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: "Glenn Michaels" Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Thu, 18 Aug 2016 13:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24102 X-GNU-PR-Package: guile X-GNU-PR-Keywords: patch Original-Received: via spool by 24102-submit@debbugs.gnu.org id=B24102.14715256556577 (code B ref 24102); Thu, 18 Aug 2016 13:08:01 +0000 Original-Received: (at 24102) by debbugs.gnu.org; 18 Aug 2016 13:07:35 +0000 Original-Received: from localhost ([127.0.0.1]:60992 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1baN2k-0001i0-Px for submit@debbugs.gnu.org; Thu, 18 Aug 2016 09:07:34 -0400 Original-Received: from orange.safe-mail.net ([212.29.227.81]:59706) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1baN2i-0001hq-LH for 24102@debbugs.gnu.org; Thu, 18 Aug 2016 09:07:33 -0400 Original-Received: by orange.safe-mail.net with Safe-mail (Exim 4.84) (envelope-from ) id 1baN2c-00087R-Nr; Thu, 18 Aug 2016 09:07:26 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=N1-0105; d=Safe-mail.net; b=r+IeCNqPeNwbxUMeFLwL5iqQbFNbjunvxChEvfn7kZGNyg57rLBvFidL7sUWSFfM Qx/8+U4a5o4yFLQqGoW331WmQX/cojeBnVw3KFirlOso3aN4kS269RBsQcfz3qOQ hxTS9ADtbxqlfHVdLUxUh8uCeHaAc+1xbt6FCvGzSuk=; Original-Received: from pc ([94.23.150.95]) by Safe-mail.net with https X-SMType: Regular X-SMRef: N1O-ZjEQGzKD9q X-SMSignature: cdraO/6yuzI+eo8xaumcS353o4SAfanB0vXSGxTCe5KEpsDkLHCbJ0+H6XjdxR6Q +XBbQ0F2II/79ELFOGwQSKZ5Je2NswJAGM8G+FGtI9VtvFpO6c5YtKj1OlC818cm wCEGASj4KbAFaE+Gpyi+QaYy+mQ5VWEjgynVYdsdqps= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.org gmane.lisp.guile.bugs:8381 Archived-At: Sorry for the delayed response. Mark H Weaver writes: > > Moreover, SRFI-111 boxes and guile variable objects are clearly > > semantically the same thing. > Unfortunately, they are not quite the same thing. Unlike SRFI-111 > boxes, Guile variables are a union type: they contain an arbitrary > Scheme value, *or* they may be "unbound". For such a simple data type, > this added complication is semantically quite significant. > As a result, some important properties of SRFI-111 boxes do not hold for > your proposed implementation. For example, in SRFI-111, (box? x) > implies that (box-ref x) will not raise an exception You're right. They aren't exactly the same, it would be more correct to say that boxes are equivalent to bound variables. Thus box? should be defined as: (define (box? o) (and (variable? o) (variable-bound? o))) That way, (box-ref o) is guaranteed to work whenever (box? o) holds. I'm suggesting that in current versions of Guile, implementing SRFI-111 boxes via variables is faster that the current implementation using records. With the definition of box? as above, it would be semantically correct. If a future guile compiler can implement boxes more efficiently in a different representation, there's nothing to stop you switching to that representation when the time comes. Making this simple change now doesn't prevent you from doing something different in future. I'm not suggesting that you should necessarily *guarantee* that boxes will always be implemented using variables. > this fact can be exploited by a compiler to produce better native code for > 'box-ref' when the type of its argument is known to be a box. In such cases, > I guess 'box-ref' can be implemented as a single load instruction, whereas > 'variable-ref' will require a conditional branch. With respect to what you say about compiler optimizations: In order to implement a given call to unbox with a single load instruction, the compiler would have to prove that the argument is a box, i.e. that it satisfies the box? predicate. You could also implement calls to variable-ref with a single load instruction in cases where the compiler can prove that the argument is a bound variable, i.e. that it satisfies (and (variable? o) (variable-bound? o)) -- precisely the definition of box? above. Therefore it seems to me that whether you can perform this optimization or not in a given case depends not so much on whether boxes and variables are distinct types, but on how much information the compiler can infer statically about each variable (in the general sense) reference at a given point the program. However, this discussing is academic insomuch as AFAICT the current guile compiler currently performs neither optimization.