Am So., 16. Juni 2019 um 11:49 Uhr schrieb Mark H Weaver : > > 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 > Hi Mark, always interested in guile developments with regard to lilypond I noticed some inconsistence with my local lilypond-using-guile-2.9.2 installation. I think I could break it down to pure guile (no lilypond) (1) The already stated behaviour: ~$ guile GNU Guile 2.9.2 Copyright (C) 1995-2019 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guile-user)> (define (function-generator) (let ((func #f)) (lambda () (set! func (let a () a)) func))) scheme@(guile-user)> (define x (function-generator)) scheme@(guile-user)> (define y (function-generator)) scheme@(guile-user)> (write (version)) "2.9.2" scheme@(guile-user)> (format #t "\nTEST: ~a" (eq? (x) (y))) TEST: #t $1 = #t (2) Doing it in a .scm-file (attached) ~$ guile --no-auto-compile eq-tst.scm "2.9.2" TEST: #f Did I something wrong or is it a bug? Cheers, Harm