From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: GNU Guile branch, wip-peval-predicates, created. v2.0.5-100-g59c5570 Date: Sat, 14 Apr 2012 17:28:29 -0700 Message-ID: <87sjg53kk2.fsf@pobox.com> References: <87zkaf4sov.fsf@netris.org> <8762d34mvv.fsf@pobox.com> <87sjg74l2b.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1334449738 31888 80.91.229.3 (15 Apr 2012 00:28:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 15 Apr 2012 00:28:58 +0000 (UTC) Cc: guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Apr 15 02:28:57 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 1SJDKl-0000aH-SP for guile-devel@m.gmane.org; Sun, 15 Apr 2012 02:28:51 +0200 Original-Received: from localhost ([::1]:50806 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SJDKk-0006cX-SY for guile-devel@m.gmane.org; Sat, 14 Apr 2012 20:28:50 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52347) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SJDKg-0006cB-KZ for guile-devel@gnu.org; Sat, 14 Apr 2012 20:28:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SJDKe-0006vv-Ix for guile-devel@gnu.org; Sat, 14 Apr 2012 20:28:46 -0400 Original-Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62]:41456 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SJDKe-0006vq-9z for guile-devel@gnu.org; Sat, 14 Apr 2012 20:28:44 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id CEEA99982; Sat, 14 Apr 2012 20:28:40 -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; s=sasl; bh=GwasjVBcXa1SiYSX4DHRLb58um8=; b=UNWTMK g7UInpVNGdE/4wUF3WKZPV1uF0NrgyVQXwCMJ/A0Ua0J9kzUQskl6o2VTfVCrH90 ja204570XVdy4ajd2RqL9SUG31BDEk5mLiww8ASjaXdEpbgVDPOOjPSCK8UW8urk dTkbbxXcgw7/7DBoFkb+47g9y/rQsCOSHCRHA= 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=IO7gXfdC5ti+MxXlfl7K8nPumjMVjgze 8BeUNY/qU2/WTsveW7n5ET9ULdsBAKRLquDkt7R9+INPt2JjY7nvAFdUNN9EnTkH DvaO5WpsFZ8C8FDPGg9qtfyh1F8Fi1lQ0V2VqtdEBTxBByPJlLGyP3OntvO1uiC8 yf9LULbNZ1k= Original-Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id C895F9980; Sat, 14 Apr 2012 20:28:40 -0400 (EDT) Original-Received: from badger (unknown [70.36.215.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id ABA02997F; Sat, 14 Apr 2012 20:28:39 -0400 (EDT) In-Reply-To: <87sjg74l2b.fsf@netris.org> (Mark H. Weaver's message of "Fri, 13 Apr 2012 13:07:40 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) X-Pobox-Relay-ID: F2DA107C-8691-11E1-BA4C-B1B0728A0A4D-02397024!a-pb-sasl-sd.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 74.115.168.62 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:14269 Archived-At: Hi, On Fri 13 Apr 2012 10:07, Mark H Weaver writes: > Nonetheless, the vtable checks involve comparisons with a mutable > top-level variable. Whenever unknown code is run (e.g. when a top-level > procedure is called) you must assume the worst: that any top-level > variable might have been 'set!'. You probably saw, but wip-cse does effects analysis to prove that the toplevel hasn't been set! by intervening expressions. There is of course the question of what optimizations like this may be made in the presence of concurrently executing threads. For example, in wip-cse the following expression folds: (if (eq? x y) (eq? x y) #f) => (eq? x y) This is because there was no toplevel-set! in between the first and second checks. The possible side effects of referencing X or Y would happen on the first check or not at all, so the second expression can cause no effects. (If CSE sees a call to an unknown procedure, it's assumed that it can cause any effect, and thus such a call does not commute with anything but a "constant" expression.) But OK, the question here is, what if another thread is concurrently mutating X and Y? If this were C++ or Java, the answer would be that they can still fold, because access to a multithreaded mutable needs to be synchronized. I think this is reasonable. What do you think? Andy -- http://wingolog.org/