From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dirk Herrmann Newsgroups: gmane.lisp.guile.devel Subject: Re: Syntax checks Date: Sun, 7 Apr 2002 09:09:36 +0200 (MEST) 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 1018163544 13940 127.0.0.1 (7 Apr 2002 07:12:24 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 7 Apr 2002 07:12:24 +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 16u6qe-0003cj-00 for ; Sun, 07 Apr 2002 09:12:24 +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 16u6qK-0005c8-00; Sun, 07 Apr 2002 03:12:04 -0400 Original-Received: from marvin.ida.ing.tu-bs.de ([134.169.132.60]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16u6o4-0005TU-00 for ; Sun, 07 Apr 2002 03:09:45 -0400 Original-Received: from localhost (dirk@localhost) by marvin.ida.ing.tu-bs.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id g3779b007086; Sun, 7 Apr 2002 09:09:37 +0200 X-Authentication-Warning: marvin.ida.ing.tu-bs.de: dirk owned process doing -bs Original-To: Neil Jerram In-Reply-To: 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:314 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:314 On 6 Apr 2002, Neil Jerram wrote: > >>>>> "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? No, certainly not. However, the evaluator has to check for it. The reason is the following: SCM_CEVAL _must_ be called with a non-immediate. That means that whereever SCM_CEVAL is to be called with some expression, the special case of an immediate has to be checked before doing the actual call. In the execution of the 'do body, every expression is checked to be an immediate, and if it isn't, then SCM_CEVAL is called. It is this kind of check (and a couple of similar ones) that I try to remove, since it slows down the evaluator. > 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.) I at least am not aware of such a general picture. But, whatever it would be like, it would require the following: * a preprocessing (or compilation) of the code in order to reduce the actual work of the evaluator to a minimum. * as a consequence, a more general way to track the relationship between source code and preprocessed (aka memoized) code. My personal strategy is to move forward in small steps and learn during that process. A complete re-write of the evaluator and all of its surrounding code (debugger, stack handling, source tracking, ...) is at least for me too complex. I don't know about the status of the other attempts that are currently made towards this goal, but it seems that there is little progress. As you may have noticed, I have already started to clean up the evaluator code (although that process is far from finished yet). The number of jump labels has been reduced, the intra-function communication has been simplified and the code has been made somewhat easier (IMO) to understand. Things are going slowly, but they are proceeding :-) > 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. I have to admit that I have not taken a look at how debugging works. If you agree, we can work together: Before doing any changes to the evaluator, I would double check with you. > Dirk> * Should warnings be issued when dead code is eliminated from the source? > > I guess it should be configurable :-) That's what I think, too. However, there are some difficulties with macros: A macro can be used perfectly fine, but resulting in a construct with some dead code. You might not be interested in warnings in such a special situation, while in all other situations you might want to be warned. I think, it is best to start with issuing warning messages to a dedicated output port and think of improvements later. Best regards Dirk Herrmann _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel