Re: Guile 2.0.9, reader: Cannot 'read' an '*unspecified*' value

[David Kastrup]

address@hidden (Taylan Ulrich "Bayırlı/Kammer") writes:

> Artyom Poptsov <address@hidden> writes:
>
>> Hello Guilers,
>>
>> it seems that currently there's no way to 'read' back an
>> '*unspecified*' value,

*unspecified* works reasonably fine in most circumstances.

scheme@(guile-user)> (make-vector 3)
$1 = #(#<unspecified> #<unspecified> #<unspecified>)
scheme@(guile-user)> #(#<unspecified> #<unspecified> #<unspecified>)
While reading expression:
ERROR: In procedure scm_lreadr: #<unknown port>:2:3: Unknown # object: #\<
scheme@(guile-user)> #(*unspecified* *unspecified* *unspecified*)
$2 = #(*unspecified* *unspecified* *unspecified*)
scheme@(guile-user)> 

It seems like printing *unspecified* as #<unspecified> is not actually
doing anybody much of a favor, though.

>> but in some cases such a feature might be handy.  Here's the
>> description of the problem; a patch is attached as well.
>
> Just my opinion: I generally see code relying on the existence of the
> *unspecified* value (let alone any specific semantics of it) to be
> sub-optimal.

See <URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17474>.  Even
while Andy Wingo steadfastly refuses to acknowledge this patch, it is an
implementation of his 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.

This patch renders *unspecified* and (values) identical (and equivalent
to SCM_UNSPECIFIED which thus is the C representation of the zero-values
object).

In spite of this patch being ignored perpetually, code relying on
*unspecified* being different from (values) in too many respects seems
imprudent.

However, it is also clear that *unspecified* in GUILE, patch or not, has
a more tangible existence than the fundamental Scheme guarantees for
(values) or any non-single-value objects are and that this is not going
to change.

While for most instances of "the return value is unspecified" it seems
like a reasonably elegant way to implement this as "the return value is
*unspecified*", I think it was a bad idea to also use this plan for "the
initial value is unspecified" as in the case of make-vector.  That
significantly reduces the options for more rigid implementations of
*unspecified* since lots of code by now relies on being able to move
*unspecified* around as part of data structures.

> Guile documents the value, so I guess there's some guarantees
> regarding its existence and semantics, but I think it's best not to
> rely on it anyway, so that #1 Guile can decide to do something else in
> the future where it currently returns *unspecified*, #2 code has
> clearer semantics, #3 code can be ported more easily to other Scheme
> platforms (say GNU Kawa), and possibly more such benefits.

[...]

> Just my two cents.  The maintainers should decide what to do. :-)

Or not.

-- 
David Kastrup