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

Previous Next

To reply to this bug, email your comments to 17474 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: David Kastrup <dak <at> gnu.org>
Cc: 17474 <at> debbugs.gnu.org
Subject: Re: bug#17474: Making *unspecified* equivalent to (values) would seem
 convenient
Date: Mon, 12 May 2014 17:53:58 +0200

R5RS defines ‘values’ 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’.

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

From: David Kastrup <dak <at> gnu.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 17474 <at> debbugs.gnu.org
Subject: Re: bug#17474: Making *unspecified* equivalent to (values) would seem
 convenient
Date: Mon, 12 May 2014 18:58:25 +0200

ludo <at> gnu.org (Ludovic Courtès) writes:

> R5RS defines ‘values’ 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) => 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.

-- 
David Kastrup

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: David Kastrup <dak <at> gnu.org>
Cc: 17474 <at> debbugs.gnu.org
Subject: Re: bug#17474: Making *unspecified* equivalent to (values) would seem
 convenient
Date: Mon, 12 May 2014 21:21:25 +0200

David Kastrup <dak <at> gnu.org> skribis:

> ludo <at> gnu.org (Ludovic Courtès) writes:
>
>> R5RS defines ‘values’ 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’m not completely convinced it makes sense to “specify” the zero values
case in this way, but I’d like to hear what others think.

Thanks,
Ludo’.

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

From: David Kastrup <dak <at> gnu.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 17474 <at> debbugs.gnu.org
Subject: Re: bug#17474: Making *unspecified* equivalent to (values) would seem
 convenient
Date: Mon, 12 May 2014 21:49:43 +0200

ludo <at> gnu.org (Ludovic Courtès) writes:

> David Kastrup <dak <at> gnu.org> skribis:
>
>> ludo <at> gnu.org (Ludovic Courtès) writes:
>>
>>> R5RS defines ‘values’ 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’m not completely convinced it makes sense to “specify” the zero values
> case in this way, but I’d 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) => ()
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.

-- 
David Kastrup

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

From: David Kastrup <dak <at> gnu.org>
To: 17474 <at> debbugs.gnu.org
Subject: Another point
Date: Sat, 21 Jun 2014 23:30:19 +0200

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 #23 received at 17474 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: David Kastrup <dak <at> gnu.org>
Cc: 17474 <at> debbugs.gnu.org
Subject: Re: bug#17474: Another point
Date: Sun, 22 Jun 2014 01:17:39 -0400

David Kastrup <dak <at> gnu.org> 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 #26 received at 17474 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: David Kastrup <dak <at> gnu.org>, 17474 <at> debbugs.gnu.org
Subject: Re: bug#17474: Making *unspecified* equivalent to (values) would seem
 convenient
Date: Sun, 22 Jun 2014 01:25:41 -0400

ludo <at> gnu.org (Ludovic Courtès) writes:
> I’m not completely convinced it makes sense to “specify” the zero values
> case in this way, but I’d 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 #29 received at 17474 <at> debbugs.gnu.org (full text, mbox):

From: David Kastrup <dak <at> gnu.org>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 17474 <at> debbugs.gnu.org
Subject: Re: bug#17474: Another point
Date: Sun, 22 Jun 2014 07:45:04 +0200

Mark H Weaver <mhw <at> netris.org> writes:

> David Kastrup <dak <at> gnu.org> 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 #32 received at 17474 <at> debbugs.gnu.org (full text, mbox):

From: David Kastrup <dak <at> gnu.org>
To: Mark H Weaver <mhw <at> netris.org>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 17474 <at> debbugs.gnu.org
Subject: Re: bug#17474: Making *unspecified* equivalent to (values) would seem
 convenient
Date: Sun, 22 Jun 2014 08:09:14 +0200

Mark H Weaver <mhw <at> netris.org> writes:

> ludo <at> gnu.org (Ludovic Courtès) writes:
>> I’m not completely convinced it makes sense to “specify” the zero values
>> case in this way, but I’d 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 1
would be this patch.  Step 2 would be putting out deprecation warnings.
Step 3 would be removing the automatic conversions.

Compatibility considerations will make the last two steps a large
hurdle.  I don't see a better step 1 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 1 done.
But every journey starts with the first step.

-- 
David Kastrup

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

From: David Kastrup <dak <at> gnu.org>
To: 17474 <at> debbugs.gnu.org
Subject: Ping?
Date: Sat, 09 Aug 2014 11:17:05 +0200

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 #40 received at 17474 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: David Kastrup <dak <at> gnu.org>
Cc: 17474 <at> debbugs.gnu.org
Subject: Re: bug#17474: Ping?
Date: Sun, 10 Aug 2014 15:12:20 -0400

David Kastrup <dak <at> gnu.org> 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 #43 received at 17474 <at> debbugs.gnu.org (full text, mbox):

From: David Kastrup <dak <at> gnu.org>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 17474 <at> debbugs.gnu.org
Subject: Re: bug#17474: Ping?
Date: Sun, 10 Aug 2014 22:26:47 +0200

Mark H Weaver <mhw <at> netris.org> writes:

> David Kastrup <dak <at> gnu.org> 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 API 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 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*))

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 API?

I'm not responsible for the discrepancy between the "no values" concept
in the C API and the Scheme layers.  It has been there starting with
GUILE 1.  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.

-- 
David Kastrup

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

From: Mark H Weaver <mhw <at> netris.org>
To: David Kastrup <dak <at> gnu.org>
Cc: 17474 <at> debbugs.gnu.org
Subject: Re: bug#17474: Ping?
Date: Sun, 10 Aug 2014 17:48:09 -0400

David Kastrup <dak <at> gnu.org> writes:

> Mark H Weaver <mhw <at> netris.org> writes:
>
>> David Kastrup <dak <at> gnu.org> 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 #49 received at 17474 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: David Kastrup <dak <at> gnu.org>
Cc: 17474 <at> debbugs.gnu.org
Subject: Re: bug#17474: Ping?
Date: Sun, 10 Aug 2014 18:00:47 -0400

David Kastrup <dak <at> gnu.org> 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 #54 received at 17474 <at> debbugs.gnu.org (full text, mbox):

From: David Kastrup <dak <at> gnu.org>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 17474 <at> debbugs.gnu.org
Subject: Re: bug#17474: Ping?
Date: Mon, 01 Jun 2015 16:04:25 +0200

Mark H Weaver <mhw <at> netris.org> writes:

> David Kastrup <dak <at> gnu.org> 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

Previous Next

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