From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.user Subject: Re: Self-evaluating function and closure Date: Sun, 16 Jun 2019 05:47:02 -0400 Message-ID: <87o92x3lqm.fsf@netris.org> References: <20190612202929.GA20126@newvzh.lokolhoz> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="148698"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Jun 16 11:50:25 2019 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hcRnq-000cXf-Pp for guile-user@m.gmane.org; Sun, 16 Jun 2019 11:50:22 +0200 Original-Received: from localhost ([::1]:38584 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hcRnp-00068q-D6 for guile-user@m.gmane.org; Sun, 16 Jun 2019 05:50:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44093) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hcRmr-00063r-1w for guile-user@gnu.org; Sun, 16 Jun 2019 05:49:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hcRmp-0000QL-Td for guile-user@gnu.org; Sun, 16 Jun 2019 05:49:20 -0400 Original-Received: from world.peace.net ([64.112.178.59]:51162) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hcRmp-0000Pm-PY for guile-user@gnu.org; Sun, 16 Jun 2019 05:49:19 -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 1hcRmo-00010R-I3; Sun, 16 Jun 2019 05:49:18 -0400 In-Reply-To: <20190612202929.GA20126@newvzh.lokolhoz> (Vladimir Zhbanov's message of "Wed, 12 Jun 2019 23:29:29 +0300") 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.23 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:15558 Archived-At: Hello again Vladimir, Vladimir Zhbanov writes: > - Is there a way to work around this (either using the above 'let' > construct or anything else)? I'm not quite sure how to answer this question because I don't know what your requirements are. If you need to generate unique tags, any mutable object will do, e.g. a vector, list or string with at least one element that is not a literal. For example, (list #f), (vector #f), and (string #\a) must allocate a fresh object every time, but (list), (vector), (string), '(#f), #(#f), and "foo" may return the same object every time. If you need to generate a unique _procedure_, there's only one future-proof way to do it: the new procedure must behave differently than every other procedure, for some input. It's a mistake to expect procedures with equivalent behavior to be distinguishable in Scheme. If you feel that you need this, I would like to understand why. Note that 'eq?' is the same as 'eqv?' when applied to procedures (and most other types), and that Scheme 'eqv?' historically implements an approximation of "operational equivalence". That language was explicit in the R3RS, which defined 'eqv?' this way: The eqv? procedure implements an approximation to the relation of operational equivalence. It returns #t if it can prove that obj1 and obj2 are operationally equivalent. If it can't, it always errs on the conservative side and returns #f. with "operational equivalence" defined as follows: Two objects are operationally equivalent if and only if there is no way that they can be distinguished, using Scheme primitives other than eqv? or eq? or those like memq and assv whose meaning is defined explicitly in terms of eqv? or eq?. It is guaranteed that objects maintain their operational identity despite being named by variables or fetched from or stored into data structures. More recent Scheme standards have dropped this language, because the Scheme authors were not entirely satisfied with this definition and were unable to formulate a better one, but nonetheless "operational equivalence" remains the closest thing I've seen to a unifying principle of the meaning of Scheme 'eqv?'. Regards, Mark