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.devel Subject: Re: RFC: (ice-9 sandbox) Date: Fri, 14 Apr 2017 12:52:19 +0200 Message-ID: <87zifj6z30.fsf@pobox.com> References: <87r31daj8n.fsf@pobox.com> <871std65px.fsf@gnu.org> <87mvc19zuo.fsf@pobox.com> <87lgrljf8n.fsf@gnu.org> <874ly79kp3.fsf@pobox.com> <87vaqlld0t.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1492167159 1471 195.159.176.226 (14 Apr 2017 10:52:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Apr 2017 10:52:39 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Apr 14 12:52:35 2017 Return-path: Envelope-to: guile-devel@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 1cyyqA-0000IW-PU for guile-devel@m.gmane.org; Fri, 14 Apr 2017 12:52:34 +0200 Original-Received: from localhost ([::1]:52710 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cyyqG-0007Cx-Cr for guile-devel@m.gmane.org; Fri, 14 Apr 2017 06:52:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cyyq8-0007Bd-Ci for guile-devel@gnu.org; Fri, 14 Apr 2017 06:52:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cyyq5-0008J4-AS for guile-devel@gnu.org; Fri, 14 Apr 2017 06:52:32 -0400 Original-Received: from pb-sasl1.pobox.com ([64.147.108.66]:54953 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cyyq5-0008Ia-5y; Fri, 14 Apr 2017 06:52:29 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 950BC6F9E7; Fri, 14 Apr 2017 06:52:27 -0400 (EDT) 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:content-transfer-encoding; s=sasl; bh=VPNwE3v4CESH wfTxmhAsrZ4gxp8=; b=Mb6iJES94WrlJcEmZelwQtG4bPHX/YtsmWCJLjOoV1Lo B/EgakWCjZOacswpsZ6V7upV9ASqDJ8ackFZWt9G0FN43oopgryD8R4eS6F1fKm4 Seyg0Bjw4sZVTe6vrAWAXKidx3cJb+DMC8KhbbgyPZa2FRIkW+5EuQs25d0yIC8= 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:content-transfer-encoding; q=dns; s=sasl; b=rgmi1U F4SOoFLuQlhP/Lh4JaFa8EmFt4C+C9t0mCVPfaRXF3cJ1FyyuY14HBd4ixBokhHE XX9B3LNGuqnQCvnTpBZuSHJVxYKAHnLvwxJ9YOgU6psRdj0qGkcF56UWMgzA3l8C m0/QQWouqR51diJsEnWHhukBKa7JnuVg/b04Q= Original-Received: from pb-sasl1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 8C7DB6F9E6; Fri, 14 Apr 2017 06:52:27 -0400 (EDT) Original-Received: from clucks (unknown [88.160.190.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl1.pobox.com (Postfix) with ESMTPSA id A37DB6F9E5; Fri, 14 Apr 2017 06:52:26 -0400 (EDT) In-Reply-To: <87vaqlld0t.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Mon, 03 Apr 2017 17:35:46 +0200") X-Pobox-Relay-ID: 72CECA44-2100-11E7-A64F-07D2064AB293-02397024!pb-sasl1.pobox.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 64.147.108.66 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.lisp.guile.devel:19105 Archived-At: On Mon 03 Apr 2017 17:35, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Riastradh=E2=80=99s document at > has this: > > Affix asterisks to the beginning and end of a globally mutable > variable. This allows the reader of the program to recognize very > easily that it is badly written! > > =E2=80=A6 but it doesn=E2=80=99t say anything about constants nor about %. > > It could be =E2=80=98all-pure-bindings=E2=80=99, or =E2=80=98*all-pure-bi= ndings*=E2=80=99, or > =E2=80=98%all-pure-bindings=E2=80=99. So, dunno, as you see fit! I feel like I would have less of a need for name sigils like *earmuffs* or %preficentiles if we had more reliably immutable data. Right now one of the functions of these sigils is to tell the reader, "Don't use append! on this data structure or you will cause spooky action-at-a-distance!" It sure would be nice to be able to use these values without worries of this kind. We don't have this immutability problem with strings because our compiled string literals are marked as immutable, and string mutators assert that the strings are mutable. We should do the same for all literal constants. We currently can't add an immutable bit to pairs due to our tagging scheme -- pairs are just two words. But we can do this easily with other data types: vectors, arrays, bytevectors, etc. (If we want to do this, anyway.) However we it is possible to do a more expensive check to see if a pair is embedded in an ELF image (or the converse, that it is allocated on the GC heap). I just looked in Guile and there are only a few dozen instances of set-car! in Guile's source and a bit more of set-cdr!, so it's conceivable to think of this being a check that we can make. If we are able to do this, we can avoid the whole discussion about SIGSEGV handlers. It would be nice of course to be able to cons an immutable pair on the heap -- so a simple GC_is_heap_ptr(x) check wouldn't suffice to prove immutability. Not sure quite what the right solution would be there. FWIW, Racket uses four words for pairs: the type tag, the hash code, and the two fields. Four words is I think the logical progression after 2 given GC's object size granularity. It would be nice to avoid having the extra words, but if we ever switched to a moving GC we would need space for a hash code I think. Thoughts on the plan for immutable literals? Concretely for this use case, assuming that we can solve the immutable literal problem, I propose to remove sigils entirely. Thoughts welcome here. Andy