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

Previous Next

Package: guile;

Reported by: David Kastrup <dak <at> gnu.org>

Date: Mon, 12 May 2014 11:41:01 UTC

Severity: wishlist

Tags: patch

Full log


View this message in rfc822 format

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: 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




This bug report was last modified 10 years and 15 days ago.

Previous Next


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