taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:
> Artyom Poptsov <poptsov.art...@gmail.com> 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
