From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.bugs Subject: Re: (+ (values 1 2)) should be 1 Date: Tue, 24 May 2011 20:25:59 -0400 Message-ID: <87ei3nk4mg.fsf@netris.org> References: <6B109ACE-F9E4-463D-8314-A19CC40D5B50@telia.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1306283193 4187 80.91.229.12 (25 May 2011 00:26:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 25 May 2011 00:26:33 +0000 (UTC) Cc: bug-guile To: Hans Aberg Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Wed May 25 02:26:30 2011 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QP1vg-0003vv-G6 for guile-bugs@m.gmane.org; Wed, 25 May 2011 02:26:28 +0200 Original-Received: from localhost ([::1]:59085 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QP1vf-00078F-DK for guile-bugs@m.gmane.org; Tue, 24 May 2011 20:26:27 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:41653) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QP1vc-000785-9Y for bug-guile@gnu.org; Tue, 24 May 2011 20:26:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QP1vb-00043M-3y for bug-guile@gnu.org; Tue, 24 May 2011 20:26:24 -0400 Original-Received: from world.peace.net ([96.39.62.75]:58125) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QP1vb-00043C-0I for bug-guile@gnu.org; Tue, 24 May 2011 20:26:23 -0400 Original-Received: from 209-6-41-222.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.41.222] helo=freedomincluded) by world.peace.net with esmtpa (Exim 4.69) (envelope-from ) id 1QP1vG-0000iv-9E; Tue, 24 May 2011 20:26:06 -0400 Original-Received: from mhw by freedomincluded with local (Exim 4.69) (envelope-from ) id 1QP1vE-0007Rt-26; Tue, 24 May 2011 20:26:00 -0400 In-Reply-To: (Hans Aberg's message of "Tue, 24 May 2011 18:13:48 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 96.39.62.75 X-BeenThere: bug-guile@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:5617 Archived-At: Hans Aberg writes: > Right, but as the result is unspecified according to the standard, the > Guile manual suggests that the value SCM_UNSPECIFIED as an > interpretation of that. I merely say that I think it would be a good > idea. Although Guile often returns SCM_UNSPECIFIED when the standards say the value would be unspecified, it does not do this in _every_ case. To do so would be very inefficient in some cases, would violate the standards in other cases, and is in general impossible. For example, the R5RS says that the result of (eq? '(a) '(a)) is unspecified. That's because some implementations are clever enough to combine the two '(a) immutable list literals into a single object, in which case #t is returned. Other implementations make two distinct copies of '(a), in which case #f is returned. Of course, efficiency requires that `eq?' be implemented as a simple pointer comparison. The "unspecified" cases are there to allow `eq?' to be implemented efficiently. The R5RS gives these examples: (eq? 2 2) ==> _unspecified_ (eq? #\A #\A) ==> _unspecified_ and also says: `Eq?''s behavior on numbers and characters is implementation-dependent, but it will always return either true or false, [...] If we were to make (eq? 2 2) return SCM_UNSPECIFIED, we would violate the requirement above. Whether `eqv?' should return SCM_UNSPECIFIED when applied to procedures is undecidable. The R5RS requires that the result is true when the procedures' location tags are equal (i.e. when they have the same identity), and requires that the result is false when the procedures would "behave differently (return different value(s) or have different side effects) for some arguments". The results in all other cases are unspecified. The R5RS gives the following example: (eqv? (lambda (x) x) (lambda (y) y)) ==> _unspecified_ Here we would need to determine whether two distinct procedures are equivalent in the sense of always returning the same values and producing the same side effects. For such procedures, we should return SCM_UNSPECIFIED. Unfortunately, this is undecidable in the general case. If we could decide this, we could also decide the halting problem. Having said all this, one could still make the case that we should attempt to return SCM_UNSPECIFIED from expressions whose values are unspecified by the standards whenever _practical_. However, doing this would prevent us from implementing extensions to many aspects of the standard. For example, within string literals, the R5RS "does not specify the effect of a backslash within a string that is not followed by a doublequote or backslash." If we were to follow your suggestion, we should make "foo\n" return SCM_UNSPECIFIED. In other words, we would be unable to add our own implementation-specific backslash escapes. Let's always keep in mind these two common rationales for unspecified behavior in language specifications: * to allow more efficient implementation * to allow extensions to the standard Best, Mark