From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.lisp.guile.user Subject: Re: Guile 2.0.9, reader: Cannot 'read' an '*unspecified*' value Date: Tue, 03 Nov 2015 16:21:18 +0100 Organization: Organization?!? Message-ID: <87lhafyuq9.fsf@fencepost.gnu.org> References: <87611jxk33.fsf@elephant.savannah> <87pozr9m7e.fsf@T420.taylan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1446564146 5413 80.91.229.3 (3 Nov 2015 15:22:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Nov 2015 15:22:26 +0000 (UTC) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Nov 03 16:22:18 2015 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZtdPd-0002gQ-JQ for guile-user@m.gmane.org; Tue, 03 Nov 2015 16:22:17 +0100 Original-Received: from localhost ([::1]:49331 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtdPc-00041G-TQ for guile-user@m.gmane.org; Tue, 03 Nov 2015 10:22:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56850) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtdPP-00040I-0R for guile-user@gnu.org; Tue, 03 Nov 2015 10:22:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZtdP5-00055b-VL for guile-user@gnu.org; Tue, 03 Nov 2015 10:22:02 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:53081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtdP5-00054T-Oy for guile-user@gnu.org; Tue, 03 Nov 2015 10:21:43 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZtdP1-00027H-0g for guile-user@gnu.org; Tue, 03 Nov 2015 16:21:39 +0100 Original-Received: from x2f43c7e.dyn.telefonica.de ([2.244.60.126]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Nov 2015 16:21:38 +0100 Original-Received: from dak by x2f43c7e.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Nov 2015 16:21:38 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 76 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f43c7e.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:R/xSVSFG/jhmVlKLptHOKxVV0NM= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:12131 Archived-At: taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes: > Artyom Poptsov 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 = #(# # #) scheme@(guile-user)> #(# # #) While reading expression: ERROR: In procedure scm_lreadr: #:2:3: Unknown # object: #\< scheme@(guile-user)> #(*unspecified* *unspecified* *unspecified*) $2 = #(*unspecified* *unspecified* *unspecified*) scheme@(guile-user)> It seems like printing *unspecified* as # 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 . 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