From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Functional record "setters", a different approach Date: Fri, 13 Apr 2012 13:26:29 -0400 Message-ID: <87obqv4k6y.fsf@netris.org> References: <87fwcaah4w.fsf@netris.org> <87r4vthpti.fsf@gnu.org> <874nsp800i.fsf@netris.org> <87vcl4203n.fsf@gnu.org> <87vcl475qs.fsf@netris.org> <874nsn1vxt.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1334338017 16127 80.91.229.3 (13 Apr 2012 17:26:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 13 Apr 2012 17:26:57 +0000 (UTC) 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 13 19:26:56 2012 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 1SIkGq-0004Yh-5e for guile-devel@m.gmane.org; Fri, 13 Apr 2012 19:26:52 +0200 Original-Received: from localhost ([::1]:60524 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SIkGp-0000ga-Dl for guile-devel@m.gmane.org; Fri, 13 Apr 2012 13:26:51 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58764) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SIkGm-0000fw-Az for guile-devel@gnu.org; Fri, 13 Apr 2012 13:26:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SIkGk-00035u-Ic for guile-devel@gnu.org; Fri, 13 Apr 2012 13:26:47 -0400 Original-Received: from world.peace.net ([96.39.62.75]:52442) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SIkGk-00035d-Be; Fri, 13 Apr 2012 13:26:46 -0400 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1SIkGb-0008Ip-Ot; Fri, 13 Apr 2012 13:26:38 -0400 In-Reply-To: <874nsn1vxt.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Fri, 13 Apr 2012 17:41:02 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 96.39.62.75 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:14266 Archived-At: Hi Ludovic! ludo@gnu.org (Ludovic Court=C3=A8s) writes: > I=E2=80=99d say =E2=80=98set-fields=E2=80=99, no? Okay, good enough. >>> Would these checks be alleviated by Andy=E2=80=99s work on peval =E2=80= =9Cpredicates=E2=80=9D? >> >> Unfortunately, no. The 'vtable' field of a struct is a mutable field, >> and in fact when a GOOPS class is redefined, the 'vtable' field of >> instances are modified. This means that it is not safe for the compiler >> to eliminate redundant calls to 'struct-vtable'. > > Oh, OK. That is eviiiil. It turns out that I had some misconceptions about this. Although it is true that the first word of a struct cell is mutated, that's actually not what 'struct-vtable' returns nowadays. Class redefinition involves a rather complicated dance described here: http://wingolog.org/archives/2009/11/09/class-redefinition-in-guile So, the result of 'struct-vtable' does not change after all, at least not for plain instances. (It's not yet clear to me whether the vtable of a redefined class object itself can be changed). Regardless, 'struct-vtable' checks usually involve comparison with the value of a mutable top-level variable, and of course the compiler must assume that mutable variables might change whenever unknown code is run (e.g. when any top-level procedure is called). >> This example is intended to convince you that 'nocheck' variants of >> struct accessors are important as a base upon which to build efficient >> higher-level constructs, at least for our own internal use. > > I view it as an important =E2=80=9Cimplementation detail=E2=80=9D, but no= t as an API to > be exposed publicly. > > What about keeping it private until we find an actual use case where it > is required outside of (srfi srfi-9)? Okay, fair enough :) Thanks, Mark