unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Zefram <zefram@fysh.org>
Cc: 16464-close@debbugs.gnu.org, request@debbugs.gnu.org
Subject: bug#16464: + folding differs between compiler and interpreter
Date: Thu, 16 Jan 2014 08:28:28 -0500	[thread overview]
Message-ID: <87lhygqcn7.fsf@netris.org> (raw)
In-Reply-To: <20140116124629.GC21945@fysh.org> (zefram@fysh.org's message of "Thu, 16 Jan 2014 12:46:29 +0000")

tags 16464 notabug
thanks

Zefram <zefram@fysh.org> writes:

> The + procedure left-folds its arguments in interpreted code and
> right-folds its arguments in compiled code.  This may or may not be a
> bug.

[...]

> R5RS and the Guile documentation are both silent about the order of
> operations in cases like this.  I do not regard either left-folding or
> right-folding per se as a bug.  A portable Scheme program obviously can't
> rely on a particular behaviour.  My concern here is that the compiler
> and interpreter don't match, making program behaviour inconsistent on
> what is notionally a single implementation.  That mismatch may be a bug.

As you suggest, this is not a bug.  The compiler is free to apply a
different ordering to each '+' and '*' within a program, which can be
used to good effect by an optimizer.

> Obviously, with exact numbers the direction of folding makes no
> difference.  But the difference is easily seen with flonums, as flonum
> addition is necessarily non-associative.

Indeed, and if you need to explicitly order the operations (and this
_is_ often needed when working with inexacts to prevent things like
catastrophic annihilation), then you can do so using extra parentheses.

BTW, there are _many_ other cases like this, where certain aspects
behavior are left unspecified, and might not only differ between the
compiler and interpreter, but might even differ between two identical
subexpressions.  Most notably, the order in which the operand and
operands of a procedure call are evaluated is left unspecified, and
again, this can be used to good effect in a compiler for optimization
purposes.  Another is that the initializers in a 'let' or 'letrec' (but
not 'letrec*') can be evaluated in any order.

However, there _are_ some related bugs that you missed.  R5RS specifies
that '-' and '/' are left-associative, which implies that that (- x y z)
must evaluate as (- (- x y) z), and similiarly for '/', but in 2.0.9
(and afaik, in all existing 2.0.x releases), we transform (- x y z) to
(- x (+ y z)), which is incorrect.

I discovered and fixed these bugs in August in the git repository, and
they will be part of Guile 2.0.10.  I also changed the order of
operations of '+' and '*' to be left-associative while I was at it, but
I later realized that this is not required, and we reserve the right to
change the order in the future.

http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=71673fba930d735c09184d5ca115882239edabb3

I'm closing this bug now.

     Thanks,
       Mark





      reply	other threads:[~2014-01-16 13:28 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-16 12:46 bug#16464: + folding differs between compiler and interpreter Zefram
2014-01-16 13:28 ` Mark H Weaver [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lhygqcn7.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=16464-close@debbugs.gnu.org \
    --cc=request@debbugs.gnu.org \
    --cc=zefram@fysh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).