From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Lucy Newsgroups: gmane.lisp.guile.devel Subject: Re: expression Date: Thu, 24 Jun 2010 02:52:26 -0500 Message-ID: References: <867048CD-FB59-4D61-A944-03E4BE4D2960@raeburn.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1277367445 15382 80.91.229.12 (24 Jun 2010 08:17:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 24 Jun 2010 08:17:25 +0000 (UTC) Cc: guile-devel@gnu.org To: Ken Raeburn Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Jun 24 10:17:23 2010 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ORhbj-0006Np-I0 for guile-devel@m.gmane.org; Thu, 24 Jun 2010 10:17:21 +0200 Original-Received: from localhost ([127.0.0.1]:36247 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ORhaa-0003Qd-0Y for guile-devel@m.gmane.org; Thu, 24 Jun 2010 04:15:12 -0400 Original-Received: from [140.186.70.92] (port=51957 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ORhFu-0007m9-21 for guile-devel@gnu.org; Thu, 24 Jun 2010 03:53:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ORhEt-0004lc-Cc for guile-devel@gnu.org; Thu, 24 Jun 2010 03:52:48 -0400 Original-Received: from mail-gx0-f169.google.com ([209.85.161.169]:41263) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ORhEt-0004lX-5D for guile-devel@gnu.org; Thu, 24 Jun 2010 03:52:47 -0400 Original-Received: by gxk5 with SMTP id 5so1502450gxk.0 for ; Thu, 24 Jun 2010 00:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=1I0O/1gSRt/nttnMhx2TMgvzScsDkzZ87igb2rhEI+c=; b=YZgXX2mYc2q+Y+Rh9nN7gJpYBX9W595JO9umsPo7g3VtkTndfAdolAqqkXwvpyij6c 1UMzk0YSplCy65xPR0oAnRhdfHxvrUTUBy7A0p3tESYEZBsAnvAKHv6Ciq32DZyyCEpB 4nyl9JpZ70MIqj6p9Zm3+TOe2shFvlIs0rMoI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=hVCrRj5gX5uDZ5SalzH+jHx2UDf+ugtzA6yOdTFpwOI1ACoHGwb29clCXF1TYNT21v vDkEmLL6IxsCGu+SQhAZFGNTW9x1orXg841QmV+NdJ4Bfmra0bmNQzHZ4wwA/m9h8IwI 5x3e+xpw7KqdGKUWX4I20WkCxsYQDMI17QXps= Original-Received: by 10.101.214.31 with SMTP id r31mr7419839anq.185.1277365966180; Thu, 24 Jun 2010 00:52:46 -0700 (PDT) Original-Received: by 10.101.68.9 with HTTP; Thu, 24 Jun 2010 00:52:26 -0700 (PDT) In-Reply-To: <867048CD-FB59-4D61-A944-03E4BE4D2960@raeburn.org> X-Google-Sender-Auth: yuEeUO6_pw5FgyMHqjqoh-uXWFw X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:10560 Archived-At: On Thu, Jun 24, 2010 at 1:55 AM, Ken Raeburn wrote: > On Jun 23, 2010, at 17:09, Michael Lucy wrote: >> Is there any scheme expression that will just get ignored when the >> scheme code is compiled? >> >> I'm generating some code with a function like: >> >> (define (gen-update-ab updatea updateb) >> =A0`(begin >> =A0 =A0 ,(if updatea `(set! a (+ a 1)) `(donothing)) >> =A0 =A0 ,(if updateb `(set! b (+ b 1)) `(donothing)))) >> >> And ideally I could replace the donothing function with something that >> will get discarded during compilation. > > A simple constant like #f or '() or 42 shouldn't cause any evaluation to = happen, unless it's the last expression and thus the value to be returned (= in which case you'd just be returning a simple constant). Ah, I see. I tried that with variables, and just assumed that if they weren't optimized out constants wouldn't be either (in retrospect not such a great assumption): scheme@(guile-user)> ,c (begin a b 1) Disassembly of #: 0 (assert-nargs-ee/locals 0) 2 (load-symbol "a") ;; a 7 (link-now) 8 (variable-ref) 9 (drop) 10 (load-symbol "b") ;; b 15 (link-now) 16 (variable-ref) 17 (drop) 18 (make-int8:1) ;; 1 19 (return) Out of curiosity, why are variables left in? Are there situations where evaluating a variable will have side-effects? Anyway, thanks! That makes life a lot simpler. > > I don't know if there's a canonical efficient way to generate it, but it = looks like "(if #f #f)" will be optimized by the current compiler into just= pushing the magic "undefined value" onto the stack. =A0Getting rid of the = push altogether *IF* the result of the expression is unused is up to the op= timizer; you shouldn't be jumping through hoops in the code you generate to= make that happen. =A0But it appears that it does happen at least in simple= cases: > > scheme@(guile-user)> ,c (begin (if #f #f) (if #f #f) 42) > Disassembly of #: > > =A0 0 =A0 =A0(assert-nargs-ee/locals 0) > =A0 2 =A0 =A0(make-int8 42) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0;; 42 > =A0 4 =A0 =A0(return) > > Hmm... here's another way, though I've no idea if RnRS lets you not have = any expressions in here: > > scheme@(guile-user)> ,c (begin) > Disassembly of #: > > =A0 0 =A0 =A0(assert-nargs-ee/locals 0) > =A0 2 =A0 =A0(void) > =A0 3 =A0 =A0(return) > > scheme@(guile-user)> ,c (begin (begin) (begin) 42) > Disassembly of #: > > =A0 0 =A0 =A0(assert-nargs-ee/locals 0) > =A0 2 =A0 =A0(make-int8 42) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0;; 42 > =A0 4 =A0 =A0(return) > > >> There are alternatives, but they're pretty ugly (significantly moreso >> in my actual code than they look below): > > Depends how you define ugliness. :-) > > Your approach expands each possible update into one S-expression. =A0So y= ou need *something* there for each one, even if it's just a constant, or an= empty "begin". > > The alternative, I think, is rearranging your code so that no expression = gets added to the list when there's nothing to do; one way to do that, off = the top of my head, would be to generate a possibly-empty list of expressio= ns rather than exactly one for each possible update, and then merge the lis= ts together. =A0Or start with an empty list, and tack S-expressions on the = front for updates that are needed, then add the "begin" and return the resu= lt. > > But in terms of the generated byte code, the constants should just go awa= y if they're not actually used, and nested "begin" lists should get flatten= ed, so I don't think it should matter much either way. > > If you want the macro expansion to be human-readable for debugging purpos= es, you could also consider putting in some kind of no-op annotation that s= houldn't generate code, for example a let loop with a meaningful label name= and no useful body, or wrapping code that actually has effects but doesn't= use the label: > > scheme@(guile-user)> ,c (begin (let no-update-needed-for-a () #f) 42) > Disassembly of #: > > =A0 0 =A0 =A0(assert-nargs-ee/locals 0) > =A0 2 =A0 =A0(br :L171) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0;; -> = 10 > =A0 6 =A0 =A0(br :L172) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0;; -> = 14 > =A010 =A0 =A0(br :L173) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0;; -> = 6 > =A014 =A0 =A0(make-int8 42) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0;; 42 > =A016 =A0 =A0(return) > > Ehh... okay, maybe there's a little work to be done for that one. :-) > > Ken