From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Hans Aberg Newsgroups: gmane.lisp.guile.bugs Subject: Re: (+ (values 1 2)) should be 1 Date: Tue, 24 May 2011 18:13:48 +0200 Message-ID: References: <6B109ACE-F9E4-463D-8314-A19CC40D5B50@telia.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1306253692 11603 80.91.229.12 (24 May 2011 16:14:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 May 2011 16:14:52 +0000 (UTC) Cc: bug-guile To: Andy Wingo Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Tue May 24 18:14:47 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 1QOuFk-0008Lx-Vu for guile-bugs@m.gmane.org; Tue, 24 May 2011 18:14:41 +0200 Original-Received: from localhost ([::1]:41517 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOuFk-0003BA-HO for guile-bugs@m.gmane.org; Tue, 24 May 2011 12:14:40 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:57552) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOuFi-00037g-Co for bug-guile@gnu.org; Tue, 24 May 2011 12:14:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOuFh-0007XB-B9 for bug-guile@gnu.org; Tue, 24 May 2011 12:14:38 -0400 Original-Received: from smtp-out21.han.skanova.net ([195.67.226.208]:49825) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOuFh-0007Wz-1B for bug-guile@gnu.org; Tue, 24 May 2011 12:14:37 -0400 Original-Received: from [10.0.1.2] (217.210.127.13) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u26619196) id 4D6517A1022FD358; Tue, 24 May 2011 18:13:51 +0200 In-Reply-To: X-Mailer: Apple Mail (2.1084) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 195.67.226.208 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:5615 Archived-At: On 24 May 2011, at 17:07, Andy Wingo wrote: >>>> The Guile manual, sec. 10.2.5.2, says that SCM_UNSPECIFIED is to be = used when the Scheme standard says the return is an unspecified value. >>>>=20 >>>> So this Lisp extension breaks off from that. If one wants it, > = perhaps, there should be some way to invoke it. >>>=20 >>> Hans, you are misreading. (+ 1) is 1 according to the R5RS. (+ = "foo") >>> is an error. (+ (values 1 2)) is unspecified, as an instance of >>> returning an unexpected number of values to a continuation, but it = is >>> not an instance of the unspecified value. >>=20 >> Andy, I think (values 1 2) should here return SCM_UNSPECIFIED first >> argument to '+', so that people will know that the standard does = leave >> the value unspecified. >=20 > That is not what the standard says. It says that the effect of > returning an unexpected number of values is unspecified, not that the > *value* is unspecified -- which wouldn't make sense anyway, as they = are > multiple values in the first place. 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. > See the R5RS, the R6RS, and the NEWS please. >=20 > ** Returning multiple values to compiled code will silently = truncate the > values to the expected number >=20 > For example, the interpreter would raise an error evaluating the = form, > `(+ (values 1 2) (values 3 4))', because it would see the operands = as > being two compound "values" objects, to which `+' does not apply. >=20 > The compiler, on the other hand, receives multiple values on the = stack, > not as a compound object. Given that it must check the number of = values > anyway, if too many values are provided for a continuation, it = chooses > to truncate those values, effectively evaluating `(+ 1 3)' instead. >=20 > The idea is that the semantics that the compiler implements is more > intuitive, and the use of the interpreter will fade out with time. > This behavior is allowed both by the R5RS and the R6RS. There are various interpretations, as they can change at any time, they = are rather useless for any regular programming. Hans