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: GIT version: values writing Date: Thu, 20 Jan 2011 22:55:10 +0100 Message-ID: References: <87fwsnzju6.fsf@gnu.org> <140431E4-7361-4F1B-A0E4-199E1272E67A@telia.com> <87mxmve0kh.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1295560535 1863 80.91.229.12 (20 Jan 2011 21:55:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 20 Jan 2011 21:55:35 +0000 (UTC) Cc: bug-guile@gnu.org To: ludo@gnu.org (=?ISO-8859-1?Q?Ludovic_Court=E8s?=) Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Thu Jan 20 22:55:30 2011 Return-path: Envelope-to: guile-bugs@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 1Pg2Ta-0008DY-BV for guile-bugs@m.gmane.org; Thu, 20 Jan 2011 22:55:30 +0100 Original-Received: from localhost ([127.0.0.1]:48961 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pg2TZ-00058K-Qa for guile-bugs@m.gmane.org; Thu, 20 Jan 2011 16:55:29 -0500 Original-Received: from [140.186.70.92] (port=53961 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pg2TL-00053x-Aj for bug-guile@gnu.org; Thu, 20 Jan 2011 16:55:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pg2TK-0006R7-00 for bug-guile@gnu.org; Thu, 20 Jan 2011 16:55:15 -0500 Original-Received: from smtp-out21.han.skanova.net ([195.67.226.208]:41216) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pg2TJ-0006Qu-M6; Thu, 20 Jan 2011 16:55:13 -0500 Original-Received: from h131n2-fre-d2.ias.bredband.telia.com (78.72.157.131) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u26619196) id 4D07517100C14677; Thu, 20 Jan 2011 22:55:11 +0100 In-Reply-To: <87mxmve0kh.fsf@gnu.org> X-Mailer: Apple Mail (2.936) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: bug-guile@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:4992 Archived-At: On 20 Jan 2011, at 22:18, Ludovic Court=E8s wrote: >>>> There seems to be a bug in GIT version when writing the 'values' =20= >>>> data >>>> type. >>>> (list 2 (values 3 4) 5) >>>> $1 =3D (2 3 5) >>> >>> This behavior is correct: in Guile 1.9, multiple-value returns are >>> truncated any time the continuation expects fewer values. >>> >>> Here, the =91values=92 call returns 3 values, but the location where = =20 >>> it=92s >>> called expects only 1, hence the automatic truncation. >> >> After the post, I saw that R5RS says the behavior is undefined. >> >> However, quietly loosing values is inviting bugs. > > I may seem sloppy, but I find it convenient. In view of that it may break code that relies on the old behavior, I =20 think it would be better to throw an exception in the case of multiple =20= values. > In the c.l.s thread you > mentioned, Joe Marshall writes: > > With the current system, if you wish to add an extra return value, =20= > you > have to adjust the code at *every* return site (provided you can > enumerate all the return sites!). In Common Lisp, unexpected return > values are silently discarded, so modifying a function to return =20 > extra > information is a local change. Discarding the extra return values is > somewhat sloppy semantically, but far more convenient from a coding > standpoint. It also says: > With this approach, > > > [E]very procedure takes exactly one argument and returns exactly one > > result. The argument and the result will always be a sequence. =20 > [...] > > An expression in tail-recursive position returns a one-element > > sequence. Continuations accept sequences containing an arbitrary > > number of elements as results. This last correspond in infix syntax to combining objects f(x), where =20= (x) may be a tuple (x_1, ..., x_k). When f return multiple values, it =20= just returns a tuple, so if sent to another function accepting that =20 number f arguments, all would work out. I am implementing this in a syntax on top of Guile, thinking of using =20= the old # for my tuples. But as it is not in R5RS, it does not matter. I'm making my own smob. >> It is discussed here, along with some other ideas. >> >> = https://groups.google.com/group/comp.lang.scheme/browse_thread/thread/b72d= 987aa6626cd2/e2f7cfa55fb51d55?hl=3Den > > Interesting thread. Yes, I am hitting some of those problems rather quickly.