From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.user Subject: Re: A value for "nothing" Date: Tue, 28 Aug 2018 02:58:37 -0400 Message-ID: <87va7vyo2q.fsf@netris.org> References: <21036238.c6yQEfjfIL@aleksandar-ixtreme-m5740> <87sh30vqmm.fsf@netris.org> <20180827080415.GB10407@tuxteam.de> <87wosbsh5m.fsf@netris.org> <87sh2zsfle.fsf@netris.org> <31c7a870-aaf2-3f0e-2ef4-be4dc783a842@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1535439533 27036 195.159.176.226 (28 Aug 2018 06:58:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 28 Aug 2018 06:58:53 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: guile-user@gnu.org To: Matt Wette Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Aug 28 08:58:49 2018 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fuXxg-0006sD-Lj for guile-user@m.gmane.org; Tue, 28 Aug 2018 08:58:48 +0200 Original-Received: from localhost ([::1]:36569 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fuXzm-0006ld-Mz for guile-user@m.gmane.org; Tue, 28 Aug 2018 03:00:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33205) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fuXz7-0006l8-M1 for guile-user@gnu.org; Tue, 28 Aug 2018 03:00:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fuXz3-0007cy-JN for guile-user@gnu.org; Tue, 28 Aug 2018 03:00:17 -0400 Original-Received: from world.peace.net ([64.112.178.59]:49834) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fuXz3-0007cI-Cj for guile-user@gnu.org; Tue, 28 Aug 2018 03:00:13 -0400 Original-Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1fuXz2-0001Yq-Bs; Tue, 28 Aug 2018 03:00:12 -0400 In-Reply-To: <31c7a870-aaf2-3f0e-2ef4-be4dc783a842@gmail.com> (Matt Wette's message of "Mon, 27 Aug 2018 17:50:14 -0700") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 64.112.178.59 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.lisp.guile.user:14800 Archived-At: Matt Wette writes: > Is it reasonable to expect that if a value can be assigned to a variable > then a predicate exists to test for that value type? So, if > > (define a (if #f #f)) > > does not signal an error then there should be a predicate to indicate the > value associated with a is unspecified? > > If the define allowed in RnRS? I don't believe there is a predicate to > test for this. (I could be wrong.) In RnRS, (define a (if #f #f)) is allowed and guaranteed to assign *some* object to 'a' without signalling an error. However, it's not specified what object will be assigned. It could be 2 or (foo bar) or "the cow jumps over the moon". So, in RnRS, there's no predicate that you could apply to 'a' and be assured that the result will be #t on all conforming implementations. Guile has always had a predicate 'unspecified?' since at least 1996, but personally I would advise against relying on its continued existence in the future. Regarding your question whether it's reasonable to expect that every object has an associated predicate to test for it, I don't know. It's an interesting question, but I wonder what would be the practical use of such an expectation? Given the fact that there are several mechanisms to add new types that are distinct from all other types, and that we occasionally add new core types to Guile that no previously extant predicate would answer #t for, you certainly cannot rely on being able to write a 'cond' statement that tests an arbitrary object using some set of predicates and be assured that at least one of those predicates will answer #t. You could write such a 'cond' statement today with that property, but for a future version of Guile you might find an object for which none of those predicates returns #t. Regards, Mark