GNU logs - #17474, boring messages

Message sent to bug-guile@HIDDEN:

Subject: bug#17474: Making *unspecified* equivalent to (values) would seem convenient
Resent-From: David Kastrup <dak@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Mon, 12 May 2014 11:41:01 +0000
Resent-Message-ID: <handler.17474.B.1399894848820 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 17474 <at> debbugs.gnu.org
From: David Kastrup <dak@HIDDEN>
Date: Mon, 12 May 2014 13:40:22 +0200
Message-ID: <87r43zuswp.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--=-=-=
Content-Type: text/plain


Guile has sort of a love/hate-relationship with SCM_UNSPECIFIED as part
of its API.  A comment in boot-9 states:

;;; {The Unspecified Value}
;;;
;;; Currently Guile represents unspecified values via one particular value,
;;; 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.

There are, of course, lots of compatibility issues involved here.  Those
can be minimized by actually making *unspecified* exactly equivalent to
(values).  Since *unspecified* is used in a lot of places as a
first-class value, can be compared and stored in variables, the cost of
this equivalence is to allow (values) in single-value contexts.

I _think_ that we are talking about behavior undefined by the Scheme
standard here.  *unspecified* has been a pure Guileism anyway in all its
aspects.  (values), however, is firmly a standard Scheme construct, and
Guile often takes the choice to map undefined behavior in those
constructs to an error, making it easier to check for code being
portable.  Conflating (values) with *unspecified* has the consequence
that single-value contexts (such as an accessor like (car x)) may
deliver zero values to a multi-value accepting continuation by producing
*unspecified* as its single value and vice versa.

Accepting this drawback leads to a reasonably nice integration of
*unspecified* with values, making SCM_UNSPECIFIED the C level
representation of (values).

The incompatibility of this patch with Guile's existing code base and
regression test, arguably a complex code base, is limited to a single
failing test written under the assumption that (if #f #f) returns
exactly one value.  The first patch rewrites that test to get along
without this assumption.  The second patch does the actual work, the
third patch documents the changed semantics.


--=-=-=
Content-Type: text/x-diff
Content-Disposition: attachment;
 filename=0001-Coverage-test-should-not-require-if-f-f-to-return-a-.patch

From 85917446d03e2562b978575b34c1f3dda105c026 Mon Sep 17 00:00:00 2001
From: David Kastrup <dak@HIDDEN>
Date: Sat, 10 May 2014 16:05:12 +0200
Subject: [PATCH 1/3] Coverage test should not require (if #f #f) to return a
 value

* test-suite/tests/coverage.test ("instrumented/executed-lines"): Use
	let rather than let-values when there may not be more than one
	value.
---
 test-suite/tests/coverage.test | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/test-suite/tests/coverage.test b/test-suite/tests/coverage.test
index 1a63353..4829a6f 100644
--- a/test-suite/tests/coverage.test
+++ b/test-suite/tests/coverage.test
@@ -60,8 +60,7 @@
                                        (begin        ;; 2
                                          (display x) ;; 3
                                          (+ x y))))  ;; 4")))
-      (let-values (((data result)
-                    (with-code-coverage
+      (let ((data (with-code-coverage
                       (lambda () (proc 1 2)))))
         (and (coverage-data? data)
              (let-values (((instr exec)
-- 
1.9.1


--=-=-=
Content-Type: text/x-diff
Content-Disposition: attachment;
 filename=0002-Make-values-equivalent-to-unspecified.patch

From 722b97a77421a2723a9edfa14b148d6d6b847430 Mon Sep 17 00:00:00 2001
From: David Kastrup <dak@HIDDEN>
Date: Wed, 7 May 2014 18:43:23 +0200
Subject: [PATCH 2/3] Make (values) equivalent to *unspecified*

module/ice-9/boot-9.scm states in a comment:

;;; {The Unspecified Value}
;;;
;;; Currently Guile represents unspecified values via one particular value,
;;; 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*))

This code remains actually valid while addressing the "it would be nice"
angle since (values) is now represented as SCM_UNSPECIFIED in the API
while being generally treated as a valid entity in implicit single-value
contexts.  Since the Scheme standard considers using zero-value
expressions in such contexts unspecified behavior, reverting to an
identifiable *unspecified* value does not appear to violate the
standard.

Factually, SCM_UNSPECIFIED has already been used in the API to signify
no usefully returned value, and the REPL already treated *unspecified*
identical to (values) as a return value in that it did not print
anything.  This interpretation is now pervasive into the Scheme/vm
level.  *unspecified* remains less ephemeral than multiple-valued
expressions since it can generally be used as a first-class value and
stored in data structures.  Consequently, data structure access may
deliver zero values to a multiple-value accepting context:

(call-with-values (lambda () (car (list *unspecified*))) list) => ()

Scheme or C calls of values will no longer create a values object when
called without argument just like they did not do so for single
arguments previously. Consequently SCM_VALUESP(SCM_UNSPECIFIED) remains
false since SCM_UNSPECIFIED, like single values, is not a values object.
---
 libguile/eval.c      | 13 +++----------
 libguile/values.c    |  6 ++++++
 libguile/vm-engine.c | 18 ++++++++++++------
 libguile/vm.c        |  8 --------
 4 files changed, 21 insertions(+), 24 deletions(-)

diff --git a/libguile/eval.c b/libguile/eval.c
index 2488ee2..46a74f1 100644
--- a/libguile/eval.c
+++ b/libguile/eval.c
@@ -231,16 +231,7 @@ truncate_values (SCM x)
       if (SCM_LIKELY (scm_is_pair (l)))
         return scm_car (l);
       else
-        {
-          scm_ithrow (scm_from_latin1_symbol ("vm-run"),
-                      scm_list_3 (scm_from_latin1_symbol ("vm-run"),
-                                  scm_from_locale_string
-                                  ("Too few values returned to continuation"),
-                                  SCM_EOL),
-                      1);
-          /* Not reached.  */
-          return SCM_BOOL_F;
-        }
+	return SCM_UNSPECIFIED;
     }
 }
 #define EVAL1(x, env) (truncate_values (eval ((x), (env))))
@@ -351,6 +342,8 @@ eval (SCM x, SCM env)
         v = scm_call_0 (producer);
         if (SCM_VALUESP (v))
           args = scm_struct_ref (v, SCM_INUM0);
+	else if (scm_is_eq (v, SCM_UNSPECIFIED))
+	  args = SCM_EOL;
         else
           args = scm_list_1 (v);
         goto apply_proc;
diff --git a/libguile/values.c b/libguile/values.c
index 670e222..12c79d5 100644
--- a/libguile/values.c
+++ b/libguile/values.c
@@ -72,6 +72,8 @@ scm_c_nvalues (SCM obj)
 {
   if (SCM_LIKELY (SCM_VALUESP (obj)))
     return scm_ilength (scm_struct_ref (obj, SCM_INUM0));
+  else if (scm_is_eq (obj, SCM_UNSPECIFIED))
+    return 0;
   else
     return 1;
 }
@@ -116,6 +118,8 @@ SCM_DEFINE (scm_values, "values", 0, 0, 1,
   SCM_VALIDATE_LIST_COPYLEN (1, args, n);
   if (n == 1)
     result = SCM_CAR (args);
+  else if (n == 0)
+    result = SCM_UNSPECIFIED;
   else
     result = scm_c_make_struct (scm_values_vtable, 0, 1, SCM_UNPACK (args));
 
@@ -130,6 +134,8 @@ scm_c_values (SCM *base, size_t nvalues)
 
   if (nvalues == 1)
     return *base;
+  else if (nvalues == 0)
+    return SCM_UNSPECIFIED;
 
   for (ret = SCM_EOL, walk = base + nvalues - 1; walk >= base; walk--)
     ret = scm_cons (*walk, ret);
diff --git a/libguile/vm-engine.c b/libguile/vm-engine.c
index c405b2b..5916cbb 100644
--- a/libguile/vm-engine.c
+++ b/libguile/vm-engine.c
@@ -266,8 +266,12 @@
     old_fp[-1] = SCM_BOOL_F;                            \
     old_fp[-2] = SCM_BOOL_F;                            \
     /* Leave proc. */                                   \
-    SCM_FRAME_LOCAL (old_fp, 1) = val;                  \
-    vp->sp = &SCM_FRAME_LOCAL (old_fp, 1);              \
+    if (SCM_UNLIKELY (scm_is_eq (val, SCM_UNSPECIFIED)))\
+      vp->sp = &SCM_FRAME_LOCAL (old_fp, 0);		\
+    else {						\
+      SCM_FRAME_LOCAL (old_fp, 1) = val;		\
+      vp->sp = &SCM_FRAME_LOCAL (old_fp, 1);		\
+    }							\
     POP_CONTINUATION_HOOK (old_fp);                     \
     NEXT (0);                                           \
   } while (0)
@@ -695,8 +699,8 @@ VM_NAME (scm_i_thread *thread, struct scm_vm *vp,
   /* receive dst:12 proc:12 _:8 nlocals:24
    *
    * Receive a single return value from a call whose procedure was in
-   * PROC, asserting that the call actually returned at least one
-   * value.  Afterwards, resets the frame to NLOCALS locals.
+   * PROC, using *unspecified* if the call did not actually return at
+   * least one value.  Afterwards, resets the frame to NLOCALS locals.
    */
   VM_DEFINE_OP (6, receive, "receive", OP2 (U8_U12_U12, X8_U24) | OP_DST)
     {
@@ -704,8 +708,10 @@ VM_NAME (scm_i_thread *thread, struct scm_vm *vp,
       scm_t_uint32 nlocals;
       UNPACK_12_12 (op, dst, proc);
       UNPACK_24 (ip[1], nlocals);
-      VM_ASSERT (FRAME_LOCALS_COUNT () > proc + 1, vm_error_no_values ());
-      LOCAL_SET (dst, LOCAL_REF (proc + 1));
+      if (SCM_UNLIKELY (FRAME_LOCALS_COUNT () <= proc + 1))
+	LOCAL_SET (dst, SCM_UNSPECIFIED);
+      else
+	LOCAL_SET (dst, LOCAL_REF (proc + 1));
       RESET_FRAME (nlocals);
       NEXT (2);
     }
diff --git a/libguile/vm.c b/libguile/vm.c
index 4516a68..ca6592b 100644
--- a/libguile/vm.c
+++ b/libguile/vm.c
@@ -479,7 +479,6 @@ static void vm_error_not_a_bytevector (const char *subr, SCM x) SCM_NORETURN SCM
 static void vm_error_not_a_struct (const char *subr, SCM x) SCM_NORETURN SCM_NOINLINE;
 static void vm_error_not_a_vector (const char *subr, SCM v) SCM_NORETURN SCM_NOINLINE;
 static void vm_error_out_of_range (const char *subr, SCM k) SCM_NORETURN SCM_NOINLINE;
-static void vm_error_no_values (void) SCM_NORETURN SCM_NOINLINE;
 static void vm_error_not_enough_values (void) SCM_NORETURN SCM_NOINLINE;
 static void vm_error_wrong_number_of_values (scm_t_uint32 expected) SCM_NORETURN SCM_NOINLINE;
 static void vm_error_continuation_not_rewindable (SCM cont) SCM_NORETURN SCM_NOINLINE;
@@ -617,13 +616,6 @@ vm_error_out_of_range (const char *subr, SCM k)
 }
 
 static void
-vm_error_no_values (void)
-{
-  vm_error ("Zero values returned to single-valued continuation",
-            SCM_UNDEFINED);
-}
-
-static void
 vm_error_not_enough_values (void)
 {
   vm_error ("Too few values returned to continuation", SCM_UNDEFINED);
-- 
1.9.1


--=-=-=
Content-Type: text/x-diff
Content-Disposition: attachment;
 filename=0003-Document-semantics-and-API-of-values-unspecified.patch

From 0cb77a1b15db2f88829879187bd28e42822704be Mon Sep 17 00:00:00 2001
From: David Kastrup <dak@HIDDEN>
Date: Sun, 11 May 2014 14:21:13 +0200
Subject: [PATCH 3/3] Document semantics and API of (values)/*unspecified*

---
 doc/ref/api-compound.texi |  4 ++--
 doc/ref/api-control.texi  | 10 ++++++++--
 doc/ref/data-rep.texi     | 20 +++++++++++++++-----
 libguile/values.c         |  5 ++++-
 4 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/doc/ref/api-compound.texi b/doc/ref/api-compound.texi
index 055de99..30d9691 100644
--- a/doc/ref/api-compound.texi
+++ b/doc/ref/api-compound.texi
@@ -1359,8 +1359,8 @@ array that uses a @code{f64vector} for storing its elements, and
 When @var{fill} is not the special @emph{unspecified} value, the new
 array is filled with @var{fill}.  Otherwise, the initial contents of
 the array is unspecified.  The special @emph{unspecified} value is
-stored in the variable @code{*unspecified*} so that for example
-@code{(make-typed-array 'u32 *unspecified* 4)} creates a uninitialized
+available as @code{*unspecified*} so that for example
+@code{(make-typed-array 'u32 *unspecified* 4)} creates an uninitialized
 @code{u32} vector of length 4.
 
 Each @var{bound} may be a positive non-zero integer @var{n}, in which
diff --git a/doc/ref/api-control.texi b/doc/ref/api-control.texi
index 4253a20..3612693 100644
--- a/doc/ref/api-control.texi
+++ b/doc/ref/api-control.texi
@@ -882,7 +882,13 @@ Delivers all of its arguments to its continuation.  Except for
 continuations created by the @code{call-with-values} procedure,
 all continuations take exactly one value.  The effect of
 passing no value or more than one value to continuations that
-were not created by @code{call-with-values} is unspecified.
+were not created by @code{call-with-values} is unspecified by the Scheme
+standard.
+
+Guile's behavior in that case is to drop all but the first value when
+given more than one value, and to use @code{*unspecified*}
+(@code{SCM_UNSPECIFIED} in@tie{}C) as an identifiable single-value
+representation of @code{(values)}.
 
 For @code{scm_values}, @var{args} is a list of arguments and the
 return is a multiple-values object which the caller can return.  In
@@ -902,7 +908,7 @@ representation.
 
 @deftypefn {C Function} size_t scm_c_nvalues (SCM obj)
 If @var{obj} is a multiple-values object, returns the number of values
-it contains.  Otherwise returns 1.
+it contains.  It returns 0 for @code{SCM_UNSPECIFIED}, and 1 otherwise.
 @end deftypefn
 
 @deftypefn {C Function} SCM scm_c_value_ref (SCM obj, size_t idx)
diff --git a/doc/ref/data-rep.texi b/doc/ref/data-rep.texi
index d0a76e9..5a6e055 100644
--- a/doc/ref/data-rep.texi
+++ b/doc/ref/data-rep.texi
@@ -444,12 +444,22 @@ representation, for obvious reasons.
 
 @deftypefn Macro SCM SCM_UNSPECIFIED
 The value returned by some (but not all) expressions that the Scheme
-standard says return an ``unspecified'' value.
+standard says return an ``unspecified'' value.  From Scheme, it is
+available as @code{*unspecified*} and is the representation of
+@code{(values)}, a `multi-valued' expression without value.
+
+As such, the standard read-eval-print loop prints nothing when some
+expression returns this value, so it's not a bad idea to return this
+when you can't think of anything else helpful.
+
+@code{*unspecified*} differs from calls of @code{values} with multiple
+arguments in that it can serve as a first-class value, be stored in
+variables, compared with @code{eq?} and used in other single-value
+contexts.
+
+The Scheme standard neither provides an @code{*unspecified*} value, nor
+does it define the behavior of @code{(values)} in single-value contexts.
 
-This is sort of a weirdly literal way to take things, but the standard
-read-eval-print loop prints nothing when the expression returns this
-value, so it's not a bad idea to return this when you can't think of
-anything else helpful.
 @end deftypefn
 
 @deftypefn Macro SCM SCM_UNDEFINED
diff --git a/libguile/values.c b/libguile/values.c
index 12c79d5..541f55f 100644
--- a/libguile/values.c
+++ b/libguile/values.c
@@ -109,7 +109,10 @@ SCM_DEFINE (scm_values, "values", 0, 0, 1,
 	    "continuations created by the @code{call-with-values} procedure,\n"
 	    "all continuations take exactly one value.  The effect of\n"
 	    "passing no value or more than one value to continuations that\n"
-	    "were not created by @code{call-with-values} is unspecified.")
+	    "were not created by @code{call-with-values} is unspecified by\n"
+	    "the Scheme standard.\n\n"
+	    "Guile in that case uses the first of multiple values,\n"
+	    "or @code{*unspecified*} when given no value.")
 #define FUNC_NAME s_scm_values
 {
   long n;
-- 
1.9.1


--=-=-=
Content-Type: text/plain


-- 
David Kastrup

--=-=-=--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: David Kastrup <dak@HIDDEN>
Subject: bug#17474: Acknowledgement (Making *unspecified* equivalent to
 (values) would seem convenient)
Message-ID: <handler.17474.B.1399894848820.ack <at> debbugs.gnu.org>
References: <87r43zuswp.fsf@HIDDEN>
X-Gnu-PR-Message: ack 17474
X-Gnu-PR-Package: guile
Reply-To: 17474 <at> debbugs.gnu.org
Date: Mon, 12 May 2014 11:41:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-guile@HIDDEN

If you wish to submit further information on this problem, please
send it to 17474 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
17474: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D17474
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-guile@HIDDEN:

Subject: bug#17474: Making *unspecified* equivalent to (values) would seem convenient
Resent-From: ludo@HIDDEN (Ludovic =?UTF-8?Q?Court=C3=A8s?=)
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Mon, 12 May 2014 15:55:03 +0000
Resent-Message-ID: <handler.17474.B17474.139991004232503 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: David Kastrup <dak@HIDDEN>
Cc: 17474 <at> debbugs.gnu.org
From: ludo@HIDDEN (Ludovic =?UTF-8?Q?Court=C3=A8s?=)
In-Reply-To: <87r43zuswp.fsf@HIDDEN> (David Kastrup's message of
 "Mon, 12 May 2014 13:40:22 +0200")
References: <87r43zuswp.fsf@HIDDEN>
User-Agent: Gnus/5.130009 (Ma Gnus v0.9) Emacs/24.3 (gnu/linux)
Date: Mon, 12 May 2014 17:53:58 +0200
Message-ID: <871tvzyovd.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

R5RS defines =E2=80=98values=E2=80=99 as:

     (define (values . things)
       (call-with-current-continuation
         (lambda (cont) (apply cont things))))

Thus, a conforming implementation must raise a run-time error when the
continuation of a (values) form expects one or more values.

Ludo=E2=80=99.

Message sent to bug-guile@HIDDEN:

Subject: bug#17474: Making *unspecified* equivalent to (values) would seem convenient
Resent-From: David Kastrup <dak@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Mon, 12 May 2014 17:04:02 +0000
Resent-Message-ID: <handler.17474.B17474.13999141848781 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: ludo@HIDDEN (Ludovic =?UTF-8?Q?Court=C3=A8s?=)
Cc: 17474 <at> debbugs.gnu.org
From: David Kastrup <dak@HIDDEN>
In-Reply-To: <8738gfyoxm.fsf@HIDDEN>
Date: Mon, 12 May 2014 18:58:25 +0200
Message-ID: <87iopbue6m.fsf@HIDDEN>
References: <87r43zuswp.fsf@HIDDEN> <8738gfyoxm.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

ludo@HIDDEN (Ludovic Court=C3=A8s) writes:

> R5RS defines =E2=80=98values=E2=80=99 as:
>
>      (define (values . things)
>        (call-with-current-continuation
>          (lambda (cont) (apply cont things))))
>
> Thus, a conforming implementation must raise a run-time error when the
> continuation of a (values) form expects one or more values.

No.  From R5RS:

 -- procedure: call-with-current-continuation proc

[...]

     The escape procedure accepts the same number of arguments as the
     continuation to the original call to
     call-with-current-continuation.  Except for continuations created
     by the `call-with-values' procedure, all continuations take
     exactly one value.  The effect of passing no value or more than
     one value to continuations that were not created by
     call-with-values is unspecified.

Please reread the last sentence.  "unspecified".  In fact, passing more
than one value to continuations that were not created by
call-with-values already does not raise a runtime error but instead just
drops the additional values:

(+ (values 4 5) 5) =3D> 9

This patch _provides_ a default value when 0 values are given.  That's
filling in a different unspecified behavior than throwing an error, but
Guile already fills in a different unspecified behavior than throwing an
error for multiple values.

So this behavior is neither out of line, nor against the standard.  It
is merely a more convenient behavior for a situation that the standard
left unspecified.

--=20
David Kastrup

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17474: Making *unspecified* equivalent to (values) would seem convenient
Resent-From: ludo@HIDDEN (Ludovic =?UTF-8?Q?Court=C3=A8s?=)
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Mon, 12 May 2014 19:22:02 +0000
Resent-Message-ID: <handler.17474.B17474.139992249126625 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17474
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: David Kastrup <dak@HIDDEN>
Cc: 17474 <at> debbugs.gnu.org
Received: via spool by 17474-submit <at> debbugs.gnu.org id=B17474.139992249126625
          (code B ref 17474); Mon, 12 May 2014 19:22:02 +0000
Received: (at 17474) by debbugs.gnu.org; 12 May 2014 19:21:31 +0000
Received: from localhost ([127.0.0.1]:32865 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Wjvn1-0006vN-1M
	for submit <at> debbugs.gnu.org; Mon, 12 May 2014 15:21:31 -0400
Received: from hera.aquilenet.fr ([141.255.128.1]:48240)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <ludo@HIDDEN>) id 1Wjvmy-0006vD-Ev
 for 17474 <at> debbugs.gnu.org; Mon, 12 May 2014 15:21:29 -0400
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id E791328BA;
 Mon, 12 May 2014 21:21:26 +0200 (CEST)
Received: from hera.aquilenet.fr ([127.0.0.1])
 by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id NmaK6YO-lroA; Mon, 12 May 2014 21:21:26 +0200 (CEST)
Received: from pluto (reverse-83.fdn.fr [80.67.176.83])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id 912DD285D;
 Mon, 12 May 2014 21:21:26 +0200 (CEST)
From: ludo@HIDDEN (Ludovic =?UTF-8?Q?Court=C3=A8s?=)
References: <87r43zuswp.fsf@HIDDEN> <8738gfyoxm.fsf@HIDDEN>
 <87iopbue6m.fsf@HIDDEN>
X-URL: http://www.fdn.fr/~lcourtes/
X-Revolutionary-Date: 23 =?UTF-8?Q?Flor=C3=A9al?= an 222 de la =?UTF-8?Q?R=C3=A9volution?=
X-PGP-Key-ID: 0xEA52ECF4
X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc
X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA  D15D 77DD 95E2 EA52 ECF4
X-OS: x86_64-unknown-linux-gnu
Date: Mon, 12 May 2014 21:21:25 +0200
In-Reply-To: <87iopbue6m.fsf@HIDDEN> (David Kastrup's message of
 "Mon, 12 May 2014 18:58:25 +0200")
Message-ID: <87egzyajm2.fsf@HIDDEN>
User-Agent: Gnus/5.130009 (Ma Gnus v0.9) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

David Kastrup <dak@HIDDEN> skribis:

> ludo@HIDDEN (Ludovic Court=C3=A8s) writes:
>
>> R5RS defines =E2=80=98values=E2=80=99 as:
>>
>>      (define (values . things)
>>        (call-with-current-continuation
>>          (lambda (cont) (apply cont things))))
>>
>> Thus, a conforming implementation must raise a run-time error when the
>> continuation of a (values) form expects one or more values.
>
> No.  From R5RS:
>
>  -- procedure: call-with-current-continuation proc
>
> [...]
>
>      The escape procedure accepts the same number of arguments as the
>      continuation to the original call to
>      call-with-current-continuation.  Except for continuations created
>      by the `call-with-values' procedure, all continuations take
>      exactly one value.  The effect of passing no value or more than
>      one value to continuations that were not created by
>      call-with-values is unspecified.

Oh indeed, I stand corrected.

> So this behavior is neither out of line, nor against the standard.  It
> is merely a more convenient behavior for a situation that the standard
> left unspecified.

Right.

I=E2=80=99m not completely convinced it makes sense to =E2=80=9Cspecify=E2=
=80=9D the zero values
case in this way, but I=E2=80=99d like to hear what others think.

Thanks,
Ludo=E2=80=99.

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17474: Making *unspecified* equivalent to (values) would seem convenient
Resent-From: David Kastrup <dak@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Mon, 12 May 2014 19:51:02 +0000
Resent-Message-ID: <handler.17474.B17474.139992425530011 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17474
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: ludo@HIDDEN (Ludovic =?UTF-8?Q?Court=C3=A8s?=)
Cc: 17474 <at> debbugs.gnu.org
Received: via spool by 17474-submit <at> debbugs.gnu.org id=B17474.139992425530011
          (code B ref 17474); Mon, 12 May 2014 19:51:02 +0000
Received: (at 17474) by debbugs.gnu.org; 12 May 2014 19:50:55 +0000
Received: from localhost ([127.0.0.1]:32900 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjwFT-0007nz-5E
	for submit <at> debbugs.gnu.org; Mon, 12 May 2014 15:50:55 -0400
Received: from fencepost.gnu.org ([208.118.235.10]:47299 ident=Debian-exim)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <dak@HIDDEN>) id 1WjwFQ-0007nr-T1
 for 17474 <at> debbugs.gnu.org; Mon, 12 May 2014 15:50:53 -0400
Received: from localhost ([127.0.0.1]:54605 helo=lola)
 by fencepost.gnu.org with esmtp (Exim 4.71)
 (envelope-from <dak@HIDDEN>)
 id 1WjwFP-0007rE-Ik; Mon, 12 May 2014 15:50:51 -0400
Received: by lola (Postfix, from userid 1000)
 id 21474E0F55; Mon, 12 May 2014 21:49:43 +0200 (CEST)
From: David Kastrup <dak@HIDDEN>
References: <87r43zuswp.fsf@HIDDEN> <8738gfyoxm.fsf@HIDDEN>
 <87iopbue6m.fsf@HIDDEN> <87egzyajm2.fsf@HIDDEN>
Date: Mon, 12 May 2014 21:49:43 +0200
In-Reply-To: <87egzyajm2.fsf@HIDDEN> ("Ludovic =?UTF-8?Q?Court=C3=A8s?="'s message of "Mon, 12
 May 2014 21:21:25 +0200")
Message-ID: <877g5qvktk.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -5.7 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.7 (-----)

ludo@HIDDEN (Ludovic Court=C3=A8s) writes:

> David Kastrup <dak@HIDDEN> skribis:
>
>> ludo@HIDDEN (Ludovic Court=C3=A8s) writes:
>>
>>> R5RS defines =E2=80=98values=E2=80=99 as:
>>>
>>>      (define (values . things)
>>>        (call-with-current-continuation
>>>          (lambda (cont) (apply cont things))))
>>>
>>> Thus, a conforming implementation must raise a run-time error when the
>>> continuation of a (values) form expects one or more values.
>>
>> No.  From R5RS:
>>
>>  -- procedure: call-with-current-continuation proc
>>
>> [...]
>>
>>      The escape procedure accepts the same number of arguments as the
>>      continuation to the original call to
>>      call-with-current-continuation.  Except for continuations created
>>      by the `call-with-values' procedure, all continuations take
>>      exactly one value.  The effect of passing no value or more than
>>      one value to continuations that were not created by
>>      call-with-values is unspecified.
>
> Oh indeed, I stand corrected.
>
>> So this behavior is neither out of line, nor against the standard.  It
>> is merely a more convenient behavior for a situation that the standard
>> left unspecified.
>
> Right.
>
> I=E2=80=99m not completely convinced it makes sense to =E2=80=9Cspecify=
=E2=80=9D the zero values
> case in this way, but I=E2=80=99d like to hear what others think.

The real awkwardness is not when feeding (values) to a single-value
continuation but rather the ability of single-value expressions being
able to pass zero values to a multi-value continuation.

In Guilev1, there was a lot of those around, and indeed
(call-with-values (lambda () (car (list (values)))) list) =3D> ()
in Guilev1.

But in Guile 2.0.9, I actually get the same, and I don't think people
reported bugs for that.

This design does not win a beauty contest.  But at least it fits several
parts of Guile and the API together in a less ugly and more satisfactory
manner than before while providing a really large amount of backward
compatibility.

I don't really know whether there are assumptions in the compiler it
might break.  So this change would certainly also want testing with
large applications and should not be introduced shortly before a stable
release.

--=20
David Kastrup

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17474: Another point
References: <87r43zuswp.fsf@HIDDEN>
In-Reply-To: <87r43zuswp.fsf@HIDDEN>
Resent-From: David Kastrup <dak@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Sat, 21 Jun 2014 21:31:02 +0000
Resent-Message-ID: <handler.17474.B17474.140338623518918 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17474
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: 17474 <at> debbugs.gnu.org
Received: via spool by 17474-submit <at> debbugs.gnu.org id=B17474.140338623518918
          (code B ref 17474); Sat, 21 Jun 2014 21:31:02 +0000
Received: (at 17474) by debbugs.gnu.org; 21 Jun 2014 21:30:35 +0000
Received: from localhost ([127.0.0.1]:56452 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WySrq-0004uW-Jl
	for submit <at> debbugs.gnu.org; Sat, 21 Jun 2014 17:30:34 -0400
Received: from fencepost.gnu.org ([208.118.235.10]:57673 ident=Debian-exim)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <dak@HIDDEN>) id 1WySrn-0004qv-Vn
 for 17474 <at> debbugs.gnu.org; Sat, 21 Jun 2014 17:30:33 -0400
Received: from localhost ([127.0.0.1]:36747 helo=lola)
 by fencepost.gnu.org with esmtp (Exim 4.71)
 (envelope-from <dak@HIDDEN>) id 1WySrn-0000hE-7z
 for 17474 <at> debbugs.gnu.org; Sat, 21 Jun 2014 17:30:31 -0400
Received: by lola (Postfix, from userid 1000)
 id 05E05E04A3; Sat, 21 Jun 2014 23:30:20 +0200 (CEST)
From: David Kastrup <dak@HIDDEN>
Date: Sat, 21 Jun 2014 23:30:19 +0200
Message-ID: <87ionu54t0.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)


It is worth pointing out that the current state of Guile is inconsistent
regarding the return value of control structures: one primitive control
structure builder is call/cc, and its normal use does not return
*unspecified* but (values):

scheme@(guile-user)> (call-with-values (lambda () (call/cc (lambda (exit) (exit)))) list)
$5 = ()


-- 
David Kastrup

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17474: Another point
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Sun, 22 Jun 2014 05:19:02 +0000
Resent-Message-ID: <handler.17474.B17474.140341431113672 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17474
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: David Kastrup <dak@HIDDEN>
Cc: 17474 <at> debbugs.gnu.org
Received: via spool by 17474-submit <at> debbugs.gnu.org id=B17474.140341431113672
          (code B ref 17474); Sun, 22 Jun 2014 05:19:02 +0000
Received: (at 17474) by debbugs.gnu.org; 22 Jun 2014 05:18:31 +0000
Received: from localhost ([127.0.0.1]:56586 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WyaAg-0003YS-Py
	for submit <at> debbugs.gnu.org; Sun, 22 Jun 2014 01:18:31 -0400
Received: from world.peace.net ([96.39.62.75]:47414 ident=hope2)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <mhw@HIDDEN>) id 1WyaAc-0003YI-TQ
 for 17474 <at> debbugs.gnu.org; Sun, 22 Jun 2014 01:18:28 -0400
Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com
 ([209.6.91.212] helo=yeeloong.lan)
 by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16)
 (Exim 4.72) (envelope-from <mhw@HIDDEN>)
 id 1WyaAW-0004nh-0f; Sun, 22 Jun 2014 01:18:20 -0400
From: Mark H Weaver <mhw@HIDDEN>
References: <87r43zuswp.fsf@HIDDEN>
 <87ionu54t0.fsf@HIDDEN>
Date: Sun, 22 Jun 2014 01:17:39 -0400
In-Reply-To: <87ionu54t0.fsf@HIDDEN> (David Kastrup's message of
 "Sat, 21 Jun 2014 23:30:19 +0200")
Message-ID: <87mwd5wmj0.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

David Kastrup <dak@HIDDEN> writes:

> It is worth pointing out that the current state of Guile is inconsistent
> regarding the return value of control structures: one primitive control
> structure builder is call/cc, and its normal use does not return
> *unspecified* but (values):
>
> scheme@(guile-user)> (call-with-values (lambda () (call/cc (lambda (exit) (exit)))) list)
> $5 = ()

The values returned are the arguments passed to 'exit'.  Normal use is
to pass the desired return value(s) to 'exit'.

     Mark

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17474: Making *unspecified* equivalent to (values) would seem convenient
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Sun, 22 Jun 2014 05:27:01 +0000
Resent-Message-ID: <handler.17474.B17474.140341479714419 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17474
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: ludo@HIDDEN (Ludovic =?UTF-8?Q?Court=C3=A8s?=)
Cc: David Kastrup <dak@HIDDEN>, 17474 <at> debbugs.gnu.org
Received: via spool by 17474-submit <at> debbugs.gnu.org id=B17474.140341479714419
          (code B ref 17474); Sun, 22 Jun 2014 05:27:01 +0000
Received: (at 17474) by debbugs.gnu.org; 22 Jun 2014 05:26:37 +0000
Received: from localhost ([127.0.0.1]:56590 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WyaIW-0003kV-NS
	for submit <at> debbugs.gnu.org; Sun, 22 Jun 2014 01:26:37 -0400
Received: from world.peace.net ([96.39.62.75]:47416 ident=hope2)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <mhw@HIDDEN>) id 1WyaIN-0003kE-Po
 for 17474 <at> debbugs.gnu.org; Sun, 22 Jun 2014 01:26:34 -0400
Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com
 ([209.6.91.212] helo=yeeloong.lan)
 by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16)
 (Exim 4.72) (envelope-from <mhw@HIDDEN>)
 id 1WyaIH-0004oV-Ne; Sun, 22 Jun 2014 01:26:21 -0400
From: Mark H Weaver <mhw@HIDDEN>
References: <87r43zuswp.fsf@HIDDEN> <8738gfyoxm.fsf@HIDDEN>
 <87iopbue6m.fsf@HIDDEN> <87egzyajm2.fsf@HIDDEN>
Date: Sun, 22 Jun 2014 01:25:41 -0400
In-Reply-To: <87egzyajm2.fsf@HIDDEN> ("Ludovic
 \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\=
 \=\?utf-8\?Q\?s\?\= message of "Mon, 12 May 2014 21:21:25 +0200")
Message-ID: <87iontwm5m.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

ludo@HIDDEN (Ludovic Court=C3=A8s) writes:
> I=E2=80=99m not completely convinced it makes sense to =E2=80=9Cspecify=
=E2=80=9D the zero values
> case in this way, but I=E2=80=99d like to hear what others think.

I'm strongly opposed to having core Guile mechanisms automatically
convert between SCM_UNSPECIFIED and zero values, which is part of what
David's patch set does.  I'd be glad to explain the reasons for my
position in a later message, but I don't have time right now.

However, I'm (cautiously) open to the idea of changing (if #f x) and
some other things to return (values) instead of *unspecified*.  I agree
that it would be cleaner, though I worry about backward compatibility
issues.  It would have to be done between major releases.

    Regards,
      Mark

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17474: Another point
Resent-From: David Kastrup <dak@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Sun, 22 Jun 2014 06:10:02 +0000
Resent-Message-ID: <handler.17474.B17474.140341737619092 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17474
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: Mark H Weaver <mhw@HIDDEN>
Cc: 17474 <at> debbugs.gnu.org
Received: via spool by 17474-submit <at> debbugs.gnu.org id=B17474.140341737619092
          (code B ref 17474); Sun, 22 Jun 2014 06:10:02 +0000
Received: (at 17474) by debbugs.gnu.org; 22 Jun 2014 06:09:36 +0000
Received: from localhost ([127.0.0.1]:56598 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Wyay7-0004xs-Ho
	for submit <at> debbugs.gnu.org; Sun, 22 Jun 2014 02:09:35 -0400
Received: from fencepost.gnu.org ([208.118.235.10]:34902 ident=Debian-exim)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <dak@HIDDEN>) id 1Wyay4-0004xi-7G
 for 17474 <at> debbugs.gnu.org; Sun, 22 Jun 2014 02:09:33 -0400
Received: from localhost ([127.0.0.1]:42207 helo=lola)
 by fencepost.gnu.org with esmtp (Exim 4.71)
 (envelope-from <dak@HIDDEN>)
 id 1Wyay2-000580-VR; Sun, 22 Jun 2014 02:09:31 -0400
Received: by lola (Postfix, from userid 1000)
 id A0A24E04E7; Sun, 22 Jun 2014 07:45:04 +0200 (CEST)
From: David Kastrup <dak@HIDDEN>
References: <87r43zuswp.fsf@HIDDEN>
 <87ionu54t0.fsf@HIDDEN> <87mwd5wmj0.fsf@HIDDEN>
Date: Sun, 22 Jun 2014 07:45:04 +0200
In-Reply-To: <87mwd5wmj0.fsf@HIDDEN> (Mark H. Weaver's message of "Sun, 
 22 Jun 2014 01:17:39 -0400")
Message-ID: <874mzdebvj.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

Mark H Weaver <mhw@HIDDEN> writes:

> David Kastrup <dak@HIDDEN> writes:
>
>> It is worth pointing out that the current state of Guile is inconsistent
>> regarding the return value of control structures: one primitive control
>> structure builder is call/cc, and its normal use does not return
>> *unspecified* but (values):
>>
>> scheme@(guile-user)> (call-with-values (lambda () (call/cc (lambda
>> (exit) (exit)))) list)
>> $5 = ()
>
> The values returned are the arguments passed to 'exit'.  Normal use is
> to pass the desired return value(s) to 'exit'.

Well, that's the point.  You'll not see anybody using a particular value
like *unspecified* for his control structures built from Scheme
primitives, and yet the C API recommends returning SCM_UNSPECIFIED.

-- 
David Kastrup

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17474: Making *unspecified* equivalent to (values) would seem convenient
Resent-From: David Kastrup <dak@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Sun, 22 Jun 2014 06:10:03 +0000
Resent-Message-ID: <handler.17474.B17474.140341737819108 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17474
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: Mark H Weaver <mhw@HIDDEN>
Cc: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>, 17474 <at> debbugs.gnu.org
Received: via spool by 17474-submit <at> debbugs.gnu.org id=B17474.140341737819108
          (code B ref 17474); Sun, 22 Jun 2014 06:10:03 +0000
Received: (at 17474) by debbugs.gnu.org; 22 Jun 2014 06:09:38 +0000
Received: from localhost ([127.0.0.1]:56600 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Wyay9-0004y6-V9
	for submit <at> debbugs.gnu.org; Sun, 22 Jun 2014 02:09:38 -0400
Received: from fencepost.gnu.org ([208.118.235.10]:34904 ident=Debian-exim)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <dak@HIDDEN>) id 1Wyay4-0004xj-J8
 for 17474 <at> debbugs.gnu.org; Sun, 22 Jun 2014 02:09:36 -0400
Received: from localhost ([127.0.0.1]:42208 helo=lola)
 by fencepost.gnu.org with esmtp (Exim 4.71)
 (envelope-from <dak@HIDDEN>)
 id 1Wyay2-000581-VV; Sun, 22 Jun 2014 02:09:31 -0400
Received: by lola (Postfix, from userid 1000)
 id 19BDDE051A; Sun, 22 Jun 2014 08:09:15 +0200 (CEST)
From: David Kastrup <dak@HIDDEN>
References: <87r43zuswp.fsf@HIDDEN> <8738gfyoxm.fsf@HIDDEN>
 <87iopbue6m.fsf@HIDDEN> <87egzyajm2.fsf@HIDDEN>
 <87iontwm5m.fsf@HIDDEN>
Date: Sun, 22 Jun 2014 08:09:14 +0200
In-Reply-To: <87iontwm5m.fsf@HIDDEN> (Mark H. Weaver's message of "Sun, 
 22 Jun 2014 01:25:41 -0400")
Message-ID: <87zjh5cw6t.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

Mark H Weaver <mhw@HIDDEN> writes:

> ludo@HIDDEN (Ludovic Court=C3=A8s) writes:
>> I=E2=80=99m not completely convinced it makes sense to =E2=80=9Cspecify=
=E2=80=9D the zero values
>> case in this way, but I=E2=80=99d like to hear what others think.
>
> I'm strongly opposed to having core Guile mechanisms automatically
> convert between SCM_UNSPECIFIED and zero values, which is part of what
> David's patch set does.  I'd be glad to explain the reasons for my
> position in a later message, but I don't have time right now.
>
> However, I'm (cautiously) open to the idea of changing (if #f x) and
> some other things to return (values) instead of *unspecified*.  I agree
> that it would be cleaner, though I worry about backward compatibility
> issues.

The C API recommends using SCM_UNSPECIFIED here.  That was never
different.  Consolidating this will not really work without declaring
SCM_UNSPECIFIED and consequently *unspecified* the same as (values).
This strategy is also sketched in a comment by Andy where *unspecified*
is defined.

What this patch does for backward compatibility reasons is treating
*unspecified* as an immediate value in single-value contexts.

This will likely always be the case in the C API where all calls of
"values" are sort of half-transparent anyway.

It is conceivable to eventually deprecate this use in Scheme proper.
This won't be doable without a migration strategy.  The conversions this
patch uses in the Scheme/VM layer are such a migration strategy.  Step=C2=
=A01
would be this patch.  Step=C2=A02 would be putting out deprecation warnings.
Step=C2=A03 would be removing the automatic conversions.

Compatibility considerations will make the last two steps a large
hurdle.  I don't see a better step=C2=A01 towards the goal of letting
(if #f x) return (values).

I readily agree that this is a mess.  Where we disagree is in the
culprit.  You consider this patch the cause of the mess, I consider this
patch consolidation of the SCM_UNSPECIFIED/*unspecified* mess already
designed into GUILE.

> It would have to be done between major releases.

In the current form of the patch, it's surprisingly backwards compatible
but of course one would not call it a mere bug fix.

It will take a number of major releases to get more than step=C2=A01 done.
But every journey starts with the first step.

--=20
David Kastrup

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17474: Ping?
References: <87r43zuswp.fsf@HIDDEN>
In-Reply-To: <87r43zuswp.fsf@HIDDEN>
Resent-From: David Kastrup <dak@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Sat, 09 Aug 2014 09:18:02 +0000
Resent-Message-ID: <handler.17474.B17474.14075758421172 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17474
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: 17474 <at> debbugs.gnu.org
Received: via spool by 17474-submit <at> debbugs.gnu.org id=B17474.14075758421172
          (code B ref 17474); Sat, 09 Aug 2014 09:18:02 +0000
Received: (at 17474) by debbugs.gnu.org; 9 Aug 2014 09:17:22 +0000
Received: from localhost ([127.0.0.1]:36056 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1XG2m9-0000Ip-4L
	for submit <at> debbugs.gnu.org; Sat, 09 Aug 2014 05:17:21 -0400
Received: from fencepost.gnu.org ([208.118.235.10]:34996 ident=Debian-exim)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <dak@HIDDEN>) id 1XG2m6-0000Ih-Bj
 for 17474 <at> debbugs.gnu.org; Sat, 09 Aug 2014 05:17:19 -0400
Received: from localhost ([127.0.0.1]:42303 helo=lola)
 by fencepost.gnu.org with esmtp (Exim 4.71)
 (envelope-from <dak@HIDDEN>) id 1XG2m5-0005GF-Dc
 for 17474 <at> debbugs.gnu.org; Sat, 09 Aug 2014 05:17:17 -0400
Received: by lola (Postfix, from userid 1000)
 id 3325EE0493; Sat,  9 Aug 2014 11:17:05 +0200 (CEST)
From: David Kastrup <dak@HIDDEN>
Date: Sat, 09 Aug 2014 11:17:05 +0200
Message-ID: <87bnru81ke.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -5.7 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.7 (-----)


Three months after its original submission with a working patch series,
this issue is not going anywhere for no discernible reason.

There has not been any response at all from anybody significantly
working on/with the master branch, and it's not like I only tried on the
bug tracker.

How about at least classifying it correctly as being "Patch Available"
to make its state more conspicuous?

-- 
David Kastrup

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 10 Aug 2014 13:16:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 10 09:16:33 2014
Received: from localhost ([127.0.0.1]:37119 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1XGSzA-0001Eq-S5
	for submit <at> debbugs.gnu.org; Sun, 10 Aug 2014 09:16:33 -0400
Received: from fencepost.gnu.org ([208.118.235.10]:53428 ident=Debian-exim)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <dak@HIDDEN>) id 1XGSz8-0001Eh-FZ
 for control <at> debbugs.gnu.org; Sun, 10 Aug 2014 09:16:31 -0400
Received: from localhost ([127.0.0.1]:60735 helo=lola)
 by fencepost.gnu.org with esmtp (Exim 4.71)
 (envelope-from <dak@HIDDEN>) id 1XGSz8-0005QS-1G
 for control <at> debbugs.gnu.org; Sun, 10 Aug 2014 09:16:30 -0400
Received: by lola (Postfix, from userid 1000)
 id 9D08CE060B; Sun, 10 Aug 2014 15:16:29 +0200 (CEST)
From: David Kastrup <dak@HIDDEN>
To: control <at> debbugs.gnu.org
Subject: None
Date: Sun, 10 Aug 2014 15:16:29 +0200
Message-ID: <878umw7adu.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -5.7 (-----)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.7 (-----)


tags 17474 patch
thankyou

-- 
David Kastrup

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17474: Ping?
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Sun, 10 Aug 2014 19:14:01 +0000
Resent-Message-ID: <handler.17474.B17474.140769799611125 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17474
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: patch
To: David Kastrup <dak@HIDDEN>
Cc: 17474 <at> debbugs.gnu.org
Received: via spool by 17474-submit <at> debbugs.gnu.org id=B17474.140769799611125
          (code B ref 17474); Sun, 10 Aug 2014 19:14:01 +0000
Received: (at 17474) by debbugs.gnu.org; 10 Aug 2014 19:13:16 +0000
Received: from localhost ([127.0.0.1]:37993 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1XGYYN-0002tN-JA
	for submit <at> debbugs.gnu.org; Sun, 10 Aug 2014 15:13:15 -0400
Received: from world.peace.net ([96.39.62.75]:40661 ident=hope4)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <mhw@HIDDEN>) id 1XGYYL-0002tE-6N
 for 17474 <at> debbugs.gnu.org; Sun, 10 Aug 2014 15:13:13 -0400
Received: from c-24-62-95-23.hsd1.ma.comcast.net ([24.62.95.23]
 helo=yeeloong.lan)
 by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16)
 (Exim 4.72) (envelope-from <mhw@HIDDEN>)
 id 1XGYYE-0000vz-Ns; Sun, 10 Aug 2014 15:13:06 -0400
From: Mark H Weaver <mhw@HIDDEN>
References: <87r43zuswp.fsf@HIDDEN>
 <87bnru81ke.fsf@HIDDEN>
Date: Sun, 10 Aug 2014 15:12:20 -0400
In-Reply-To: <87bnru81ke.fsf@HIDDEN> (David Kastrup's message of
 "Sat, 09 Aug 2014 11:17:05 +0200")
Message-ID: <874mxkrwff.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

David Kastrup <dak@HIDDEN> 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.  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.

      Mark

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17474: Ping?
Resent-From: David Kastrup <dak@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Sun, 10 Aug 2014 20:27:02 +0000
Resent-Message-ID: <handler.17474.B17474.140770241222679 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17474
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: patch
To: Mark H Weaver <mhw@HIDDEN>
Cc: 17474 <at> debbugs.gnu.org
Received: via spool by 17474-submit <at> debbugs.gnu.org id=B17474.140770241222679
          (code B ref 17474); Sun, 10 Aug 2014 20:27:02 +0000
Received: (at 17474) by debbugs.gnu.org; 10 Aug 2014 20:26:52 +0000
Received: from localhost ([127.0.0.1]:38051 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1XGZhb-0005ti-HK
	for submit <at> debbugs.gnu.org; Sun, 10 Aug 2014 16:26:51 -0400
Received: from fencepost.gnu.org ([208.118.235.10]:58549 ident=Debian-exim)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <dak@HIDDEN>) id 1XGZhZ-0005ta-8u
 for 17474 <at> debbugs.gnu.org; Sun, 10 Aug 2014 16:26:50 -0400
Received: from localhost ([127.0.0.1]:37623 helo=lola)
 by fencepost.gnu.org with esmtp (Exim 4.71)
 (envelope-from <dak@HIDDEN>)
 id 1XGZhY-0004jm-5E; Sun, 10 Aug 2014 16:26:48 -0400
Received: by lola (Postfix, from userid 1000)
 id B2381E060B; Sun, 10 Aug 2014 22:26:47 +0200 (CEST)
From: David Kastrup <dak@HIDDEN>
References: <87r43zuswp.fsf@HIDDEN>
 <87bnru81ke.fsf@HIDDEN> <874mxkrwff.fsf@HIDDEN>
Date: Sun, 10 Aug 2014 22:26:47 +0200
In-Reply-To: <874mxkrwff.fsf@HIDDEN> (Mark H. Weaver's message of "Sun, 
 10 Aug 2014 15:12:20 -0400")
Message-ID: <87vbq05bw8.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -5.7 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.7 (-----)

Mark H Weaver <mhw@HIDDEN> writes:

> David Kastrup <dak@HIDDEN> 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

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17474: Ping?
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Sun, 10 Aug 2014 21:50:02 +0000
Resent-Message-ID: <handler.17474.B17474.140770735630540 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17474
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: patch
To: David Kastrup <dak@HIDDEN>
Cc: 17474 <at> debbugs.gnu.org
Received: via spool by 17474-submit <at> debbugs.gnu.org id=B17474.140770735630540
          (code B ref 17474); Sun, 10 Aug 2014 21:50:02 +0000
Received: (at 17474) by debbugs.gnu.org; 10 Aug 2014 21:49:16 +0000
Received: from localhost ([127.0.0.1]:38070 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1XGazM-0007wV-8y
	for submit <at> debbugs.gnu.org; Sun, 10 Aug 2014 17:49:16 -0400
Received: from world.peace.net ([96.39.62.75]:40753 ident=hope5)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <mhw@HIDDEN>) id 1XGazJ-0007wJ-IY
 for 17474 <at> debbugs.gnu.org; Sun, 10 Aug 2014 17:49:14 -0400
Received: from c-24-62-95-23.hsd1.ma.comcast.net ([24.62.95.23]
 helo=yeeloong.lan)
 by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16)
 (Exim 4.72) (envelope-from <mhw@HIDDEN>)
 id 1XGaz4-0001H0-DT; Sun, 10 Aug 2014 17:48:58 -0400
From: Mark H Weaver <mhw@HIDDEN>
References: <87r43zuswp.fsf@HIDDEN>
 <87bnru81ke.fsf@HIDDEN> <874mxkrwff.fsf@HIDDEN>
 <87vbq05bw8.fsf@HIDDEN>
Date: Sun, 10 Aug 2014 17:48:09 -0400
In-Reply-To: <87vbq05bw8.fsf@HIDDEN> (David Kastrup's message of
 "Sun, 10 Aug 2014 22:26:47 +0200")
Message-ID: <87zjfcqana.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

David Kastrup <dak@HIDDEN> writes:

> Mark H Weaver <mhw@HIDDEN> writes:
>
>> David Kastrup <dak@HIDDEN> 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?

It was a typo.  I meant SCM_UNSPECIFIED.  Anyway, I don't have time now
to continue arguing with you about this issue.  Sorry.

      Mark

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17474: Ping?
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Sun, 10 Aug 2014 22:02:01 +0000
Resent-Message-ID: <handler.17474.B17474.140770811131750 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17474
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: patch
To: David Kastrup <dak@HIDDEN>
Cc: 17474 <at> debbugs.gnu.org
Received: via spool by 17474-submit <at> debbugs.gnu.org id=B17474.140770811131750
          (code B ref 17474); Sun, 10 Aug 2014 22:02:01 +0000
Received: (at 17474) by debbugs.gnu.org; 10 Aug 2014 22:01:51 +0000
Received: from localhost ([127.0.0.1]:38076 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1XGbBW-0008G2-Od
	for submit <at> debbugs.gnu.org; Sun, 10 Aug 2014 18:01:51 -0400
Received: from world.peace.net ([96.39.62.75]:40768 ident=hope8)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <mhw@HIDDEN>) id 1XGbBU-0008Fs-3I
 for 17474 <at> debbugs.gnu.org; Sun, 10 Aug 2014 18:01:48 -0400
Received: from c-24-62-95-23.hsd1.ma.comcast.net ([24.62.95.23]
 helo=yeeloong.lan)
 by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16)
 (Exim 4.72) (envelope-from <mhw@HIDDEN>)
 id 1XGbBI-0001LX-Dm; Sun, 10 Aug 2014 18:01:36 -0400
From: Mark H Weaver <mhw@HIDDEN>
References: <87r43zuswp.fsf@HIDDEN>
 <87bnru81ke.fsf@HIDDEN> <874mxkrwff.fsf@HIDDEN>
 <87vbq05bw8.fsf@HIDDEN>
Date: Sun, 10 Aug 2014 18:00:47 -0400
In-Reply-To: <87vbq05bw8.fsf@HIDDEN> (David Kastrup's message of
 "Sun, 10 Aug 2014 22:26:47 +0200")
Message-ID: <87vbq0qa28.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

David Kastrup <dak@HIDDEN> writes:
> 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 don't have time to continue this discussion, but I wanted to respond
to this one point: there should be a single global statically-allocated
instance of the multiple-values object containing zero values, and the
procedures that create multiple-values objects would always use that
one.

      Mark

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 20 Sep 2014 09:26:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 20 05:26:34 2014
Received: from localhost ([127.0.0.1]:46369 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1XVGw5-0002y1-Ao
	for submit <at> debbugs.gnu.org; Sat, 20 Sep 2014 05:26:33 -0400
Received: from world.peace.net ([96.39.62.75]:48735)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <mhw@HIDDEN>) id 1XVGw2-0002xn-74
 for control <at> debbugs.gnu.org; Sat, 20 Sep 2014 05:26:31 -0400
Received: from c-98-217-13-77.hsd1.ma.comcast.net ([98.217.13.77]
 helo=yeeloong.lan)
 by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16)
 (Exim 4.72) (envelope-from <mhw@HIDDEN>)
 id 1XVGvw-0005Ew-0A; Sat, 20 Sep 2014 05:26:24 -0400
From: Mark H Weaver <mhw@HIDDEN>
To: control <at> debbugs.gnu.org
Date: Sat, 20 Sep 2014 05:24:28 -0400
Message-ID: <87a95umypf.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  severity 17474 wishlist thanks [...] 
 Content analysis details:   (2.0 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.8 MISSING_SUBJECT        Missing Subject: header
 0.2 NO_SUBJECT             Extra score for no subject
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  severity 17474 wishlist thanks [...] 
 
 Content analysis details:   (2.0 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  1.8 MISSING_SUBJECT        Missing Subject: header
  0.2 NO_SUBJECT             Extra score for no subject

severity 17474 wishlist
thanks

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#17474: Ping?
Resent-From: David Kastrup <dak@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Mon, 01 Jun 2015 14:10:04 +0000
Resent-Message-ID: <handler.17474.B17474.14331677941811 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 17474
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: patch
To: Mark H Weaver <mhw@HIDDEN>
Cc: 17474 <at> debbugs.gnu.org
Received: via spool by 17474-submit <at> debbugs.gnu.org id=B17474.14331677941811
          (code B ref 17474); Mon, 01 Jun 2015 14:10:04 +0000
Received: (at 17474) by debbugs.gnu.org; 1 Jun 2015 14:09:54 +0000
Received: from localhost ([127.0.0.1]:36214 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YzQPa-0000T8-9A
	for submit <at> debbugs.gnu.org; Mon, 01 Jun 2015 10:09:54 -0400
Received: from fencepost.gnu.org ([208.118.235.10]:40855 ident=Debian-exim)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <dak@HIDDEN>) id 1YzQPX-0000T0-SS
 for 17474 <at> debbugs.gnu.org; Mon, 01 Jun 2015 10:09:52 -0400
Received: from localhost ([127.0.0.1]:50517 helo=lola)
 by fencepost.gnu.org with esmtp (Exim 4.71)
 (envelope-from <dak@HIDDEN>)
 id 1YzQPW-0003ZU-VY; Mon, 01 Jun 2015 10:09:51 -0400
Received: by lola (Postfix, from userid 1000)
 id 757A8DF4C9; Mon,  1 Jun 2015 16:04:25 +0200 (CEST)
From: David Kastrup <dak@HIDDEN>
References: <87r43zuswp.fsf@HIDDEN>
 <87bnru81ke.fsf@HIDDEN> <874mxkrwff.fsf@HIDDEN>
 <87vbq05bw8.fsf@HIDDEN> <87vbq0qa28.fsf@HIDDEN>
Date: Mon, 01 Jun 2015 16:04:25 +0200
In-Reply-To: <87vbq0qa28.fsf@HIDDEN> (Mark H. Weaver's message of "Sun, 
 10 Aug 2014 18:00:47 -0400")
Message-ID: <87twurcyom.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

Mark H Weaver <mhw@HIDDEN> writes:

> David Kastrup <dak@HIDDEN> writes:
>> 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 don't have time to continue this discussion, but I wanted to respond
> to this one point: there should be a single global
> statically-allocated instance of the multiple-values object containing
> zero values, and the procedures that create multiple-values objects
> would always use that one.

So we are in agreement that a single object (I don't see a meaningful
distinction between "immediate" and "single global statically-allocated"
that is consistently being used) with SCM_NO_VALUES semantics makes
sense.

Where we don't agree is about making it the same as SCM_UNSPECIFIED.  It
is my contention that the concepts for SCM_NO_VALUES and SCM_UNSPECIFIED
overlap too much to offer the user a meaningful distinction allowing him
to make a qualified choice between returning one of the two.

I consider it a good hint that the REPL already considers *unspecified*
and (values) similar enough that it prints exactly the same for either
input, namely nothing.

So I'm pretty convinced that the user is better off without having to
deal with two separate representations of "no useful value".

-- 
David Kastrup

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.