From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: Syntax checks Date: 06 Apr 2002 16:38:36 +0100 Sender: guile-devel-admin@gnu.org Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1018123225 21366 127.0.0.1 (6 Apr 2002 20:00:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 6 Apr 2002 20:00:25 +0000 (UTC) Cc: Guile Development List Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16twMK-0005YV-00 for ; Sat, 06 Apr 2002 22:00:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16twM2-0004ps-00; Sat, 06 Apr 2002 15:00:06 -0500 Original-Received: from mail.uklinux.net ([80.84.72.21] helo=s1.uklinux.net) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16twLi-0004nJ-00 for ; Sat, 06 Apr 2002 14:59:46 -0500 Original-Received: from portalet.ossau.uklinux.net (IDENT:root@ppp-3a-109.3com.telinco.net [212.159.132.109]) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id g36JxNw13082; Sat, 6 Apr 2002 20:59:23 +0100 Original-Received: from laruns.ossau.uklinux.net.ossau.uklinux.net (neil@laruns.ossau.uklinux.net [192.168.1.3]) by portalet.ossau.uklinux.net (8.9.3/8.8.7) with ESMTP id QAA03256; Sat, 6 Apr 2002 16:42:10 +0100 Original-To: Dirk Herrmann In-Reply-To: Original-Lines: 57 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:311 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:311 >>>>> "Dirk" == Dirk Herrmann writes: Dirk> Hello everybody, Dirk> in the evaluator, there are a lot of syntax checks performed that could Dirk> probably better be performed in a previous syntax checking phase, keeping Dirk> the evaluator itself free of such checks. Dirk> As an example, there is the 'do loop construct: In the body of the do loop Dirk> you only have to execute expressions that can have a side effect. We do Dirk> not have a proper analysis for which expressions can have a side effect Dirk> and which don't, but there is a simple syntactic criterion that can be Dirk> used: If the expression is not a list, then it is an object or a variable Dirk> reference and can't have sideeffects. Dirk> Thus, the body of the do loop could be scanned in the macro transformer Dirk> and freed of unnecessary expressions. Then, the corresponding check in Dirk> the evaluator could be removed. What you say makes sense, but I'm struggling to see why it's really worth doing this. Are you aware of a lot of code that puts pointless expressions in `do' bodies? Also, does this fit into a more general picture of how we should evolve the interactions between transformation, evaluation, compilation etc.? (I don't claim that such a picture exists, but it would be nicer if it did.) Dirk> I would like to apply such changes, but I have some questions: Dirk> * Removing unnecessary expressions from code would change the source in a Dirk> way that can't be restored by unmemoizing. Do we care? In the long run Dirk> we will probably want to allow more transformations on the source anyway Dirk> for the sake of optimization. Then, memoization/unmemoization won't work Dirk> and we will have to provide a different mechanism to record the Dirk> relationship between transformed code and the source. I don't have much experience here, but your general point sounds right to me. That is, rather than unmemoizing, we may eventually need just to keep a copy of the original source. >From the debugging point of view, the requirements are that - breakpoint positions are preserved as code is transformed - when a breakpoint is hit, it is possible to map back from the transformed breakpoint location to the coordinates of the breakpoint in the original source. Dirk> * Should warnings be issued when dead code is eliminated from the source? I guess it should be configurable :-) It isn't currently possible to set source properties on something that isn't a pair, so at least you don't need to worry about eliminating code with important source properties on it (such as a breakpoint). Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel