GNU bug report logs - #17474
Making *unspecified* equivalent to (values) would seem convenient

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: David Kastrup <dak <at> gnu.org>
To: bug-guile <at> gnu.org
Subject: Making *unspecified* equivalent to (values) would seem convenient
Date: Mon, 12 May 2014 13:40:22 +0200

[Message part 1 (text/plain, inline)]

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.

[0001-Coverage-test-should-not-require-if-f-f-to-return-a-.patch (text/x-diff, attachment)]

[0002-Make-values-equivalent-to-unspecified.patch (text/x-diff, attachment)]

[0003-Document-semantics-and-API-of-values-unspecified.patch (text/x-diff, attachment)]

[Message part 5 (text/plain, inline)]

-- 
David Kastrup

Previous Next

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