bug#17474: Ping?

[David Kastrup]

Mark H Weaver <address@hidden> writes:

> David Kastrup <address@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 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