From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.lisp.guile.bugs Subject: bug#17474: Ping? Date: Sun, 10 Aug 2014 22:26:47 +0200 Message-ID: <87vbq05bw8.fsf@fencepost.gnu.org> References: <87r43zuswp.fsf@fencepost.gnu.org> <87bnru81ke.fsf@fencepost.gnu.org> <874mxkrwff.fsf@yeeloong.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1407702438 23373 80.91.229.3 (10 Aug 2014 20:27:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Aug 2014 20:27:18 +0000 (UTC) Cc: 17474@debbugs.gnu.org To: Mark H Weaver Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Sun Aug 10 22:27:11 2014 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XGZhs-00077S-FS for guile-bugs@m.gmane.org; Sun, 10 Aug 2014 22:27:08 +0200 Original-Received: from localhost ([::1]:60889 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGZhr-0002Mx-GU for guile-bugs@m.gmane.org; Sun, 10 Aug 2014 16:27:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58166) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGZhn-0002Ms-Tn for bug-guile@gnu.org; Sun, 10 Aug 2014 16:27:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XGZhm-0002z0-Qk for bug-guile@gnu.org; Sun, 10 Aug 2014 16:27:03 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59341) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGZhm-0002yw-NN for bug-guile@gnu.org; Sun, 10 Aug 2014 16:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XGZhm-0005u9-7B for bug-guile@gnu.org; Sun, 10 Aug 2014 16:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: David Kastrup Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sun, 10 Aug 2014 20:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17474 X-GNU-PR-Package: guile X-GNU-PR-Keywords: patch Original-Received: via spool by 17474-submit@debbugs.gnu.org id=B17474.140770241222679 (code B ref 17474); Sun, 10 Aug 2014 20:27:02 +0000 Original-Received: (at 17474) by debbugs.gnu.org; 10 Aug 2014 20:26:52 +0000 Original-Received: from localhost ([127.0.0.1]:38051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XGZhb-0005ti-HK for submit@debbugs.gnu.org; Sun, 10 Aug 2014 16:26:51 -0400 Original-Received: from fencepost.gnu.org ([208.118.235.10]:58549 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XGZhZ-0005ta-8u for 17474@debbugs.gnu.org; Sun, 10 Aug 2014 16:26:50 -0400 Original-Received: from localhost ([127.0.0.1]:37623 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGZhY-0004jm-5E; Sun, 10 Aug 2014 16:26:48 -0400 Original-Received: by lola (Postfix, from userid 1000) id B2381E060B; Sun, 10 Aug 2014 22:26:47 +0200 (CEST) In-Reply-To: <874mxkrwff.fsf@yeeloong.lan> (Mark H. Weaver's message of "Sun, 10 Aug 2014 15:12:20 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org 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:7532 Archived-At: Mark H Weaver writes: > David Kastrup writes: >> Three months after its original submission with a working patch series, >> this issue is not going anywhere for no discernible reason. > > As I've already said, I'm strongly opposed to your patch series. > Rigging the core procedure call mechanisms to automatically convert > between a single value of SCM_UNDEFINED and zero values is terrible, for > multiple reasons. Is this a typo or do you really think that we are talking about SCM_UNDEFINED here? If so, I would share your sentiment. But this patch is about SCM_UNSPECIFIED. To reduce the possibility for confusion of the two, it might make sense to also establish a different name, like SCM_NOVALUE or similar. But a better name is not the issue of this particular patch. SCM_UNSPECIFIED is is the _only_ documented and suggested "value" in the C=A0API to signify "no useful value". It is the value that the REPL prints identically to (values), being de facto the C representation of the (values) concept. > It muddies the semantics and adds overhead to a mechanism that needs > to be as simple and lightweight as we can possibly make it, especially > when we move to native code generation. So you think that it will be more "lightweight" if (values) does not have an immediate representation but rather creates a multiple-values object on the heap? I disagree. Particularly when you move to native code generation, you will need a heap-less representation of (values) whenever going through generic API routines. What representation do you propose for that? Why would you want a non-immediate representation for it? Where we differ in our estimate is that you do not want to see that the mess is already _there_. That is the reason that Andy has written in ice-9/boot-9.scm ;;; {The Unspecified Value} ;;; ;;; Currently Guile represents unspecified values via one particular va= lue, ;;; which may be obtained by evaluating (if #f #f). It would be nice in= the ;;; future if we could replace this with a return of 0 values, though. ;;; (define-syntax *unspecified* (identifier-syntax (if #f #f))) (define (unspecified? v) (eq? v *unspecified*)) You won't get there in any useful manner _without_ providing a lightweight presentation of (values) in the C API. I fail to see your proposal for that. Now you are not the author of the above passage. Andy is. Too bad he does not comment. If you want to move to a state where *unspecified* as well as (values) will refuse to work in a single-value context, you need a migration strategy. I fail to see your proposal for one. This here, make no mistake, _is_ a migration strategy. It will allow for making (values) and *unspecified* identical _without_ breaking the existing C API. And in GUILE 3.0 or GUILE 4.0, one might possibly _end_ automatic conversion back and forth in single-value contexts of the VM without breaking too much legacy code. Likely with one intermediate version that continues doing the conversion but while delivering deprecation warnings. What _other_ migration strategy do you propose to move *unspecified* to (values) in the C=A0API? I'm not responsible for the discrepancy between the "no values" concept in the C=A0API and the Scheme layers. It has been there starting with GUILE=A01. Without admitting that there is a problem, and without a strategy for dealing with it, it will stay in perpetuity. There is the possibility of creating an immediate SCM_NOVALUES representation in the C layer that is different from SCM_UNSPECIFIED. So when are people going to use SCM_NOVALUES and when SCM_UNSPECIFIED? Apparently it is hard enough already to usefully tell apart SCM_UNSPECIFIED and SCM_UNDEFINED and know when to apply which. You don't want a mess, and that's a useful sentiment. But the mess is there already, and not recognizing it will not help in getting it cleaned up eventually. At any rate, we may fight back and forth over it all we like. Only one person is calling the shots with regard to forward-looking language development. --=20 David Kastrup