From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.bugs Subject: bug#24102: Use guile variable objects as SRFI-111 boxes. Date: Wed, 01 Mar 2017 09:51:29 +0100 Message-ID: <87fuixjs6m.fsf@pobox.com> References: <87pop6uk9r.fsf@netris.org> <87wpixjoom.fsf@pobox.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1488358344 10347 195.159.176.226 (1 Mar 2017 08:52:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Mar 2017 08:52:24 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: 24102@debbugs.gnu.org, Glenn Michaels To: Mark H Weaver Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Wed Mar 01 09:52:18 2017 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 1cizzY-0001Dy-Ea for guile-bugs@m.gmane.org; Wed, 01 Mar 2017 09:52:12 +0100 Original-Received: from localhost ([::1]:39123 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cizzY-0007eW-DL for guile-bugs@m.gmane.org; Wed, 01 Mar 2017 03:52:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38519) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cizzT-0007a2-8m for bug-guile@gnu.org; Wed, 01 Mar 2017 03:52:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cizzO-0006Wc-Dd for bug-guile@gnu.org; Wed, 01 Mar 2017 03:52:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34524) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cizzO-0006WY-6s for bug-guile@gnu.org; Wed, 01 Mar 2017 03:52:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cizzN-0007Ji-R3 for bug-guile@gnu.org; Wed, 01 Mar 2017 03:52:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Andy Wingo Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Wed, 01 Mar 2017 08:52: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.148835830028098 (code B ref 24102); Wed, 01 Mar 2017 08:52:01 +0000 Original-Received: (at 24102) by debbugs.gnu.org; 1 Mar 2017 08:51:40 +0000 Original-Received: from localhost ([127.0.0.1]:60956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cizz1-0007J7-Nv for submit@debbugs.gnu.org; Wed, 01 Mar 2017 03:51:39 -0500 Original-Received: from pb-sasl1.pobox.com ([64.147.108.66]:55749 helo=sasl.smtp.pobox.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cizyz-0007J0-T4 for 24102@debbugs.gnu.org; Wed, 01 Mar 2017 03:51:38 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 7DD8B48DBC; Wed, 1 Mar 2017 03:51:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=1FFTIkwuhYzkRbO8aRIG1ONhGT4=; b=lqzoHi B54X3OeOqcQ6jheajL2f9sLtrGWGPRxz/z08MiEqU8dg28Z+PuXJvGC6axYJCpdX j6daWFjT7rA2aTrMSEFJUgTh2O3yfvjyVczUx2SVCiY8s+68B+1D/hcYRMHrJHlA pKciN7/Zk+12pBKyQQVJqlk1SvH47RY//9PFU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=CkBTlTXv1lKukGtIDNQzdQP7HxEQ92QS 7e3SLeT21yfXKfbkC4lMvxK/EauFgkdO+gx04r+aZC/SOEeq6pPZTqMmVDo8VaFw BQFfRws4NKF23r3FdaYBweGuh2AlUxWtSoLd/h1e9ipyZre6hek0+1SoHmovAK7K 06dpSxNcBK8= Original-Received: from pb-sasl1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 6757548DBA; Wed, 1 Mar 2017 03:51:37 -0500 (EST) Original-Received: from clucks (unknown [109.190.228.233]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl1.pobox.com (Postfix) with ESMTPSA id 747EB48DB9; Wed, 1 Mar 2017 03:51:36 -0500 (EST) In-Reply-To: <87wpixjoom.fsf@pobox.com> (Andy Wingo's message of "Wed, 31 Aug 2016 11:03:05 +0200") X-Pobox-Relay-ID: 47366E08-FE5C-11E6-AF44-B667064AB293-02397024!pb-sasl1.pobox.com 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:8602 Archived-At: On Wed 31 Aug 2016 11:03, Andy Wingo writes: > On Thu 18 Aug 2016 18:14, Mark H Weaver writes: > >> As I wrote above, the current guile compiler can already do this kind of >> type inference, although it does not currently do this for boxes. >> we can already anticipate having native code generation in the >> next couple of years, and we must keep boxes semantically simple so that >> our future compiler will be able to generate good code for this very >> important fundamental type. > > For what it's worth, I don't see the optimization argument as weighing > very heavily on this discussion. I would rather have fewer fundamental > data types rather than more, in the next two years or so. I see the > mid-term result here being that SRFI-111 boxes are much slower than > variables. > > The highest performance compilation tier we can imagine would include > adaptive optimization, and when it runs you can know that the variables > that a bit of code uses are bound or not. Also in that case we can > reasonably make any call to variable-unset! deoptimize any code that > uses variables, forcing it to reoptimize later. Since variable-unset! > is quite rare this is no big deal I think. Following up here :) So again I think the optimization argument is not so important; if that were the only consideration then IMO the balance of things would be that we should apply Glenn's patch. There is a semantic consideration as well -- box-ref on a box created by make-box should never throw an exception, and code that uses the SRFI-111 should be able to rely on this. We should probably not introduce a gratuitous incompatibility here. I propose to add a flag to variables indicating that certain variables may not be unset. We can also consider reversing this, in that only variables with the flag can be unset; my understanding is that the only user of variable-unset! is the Elisp language on variables that it creates, so that would be acceptable too. Andy