leaky let*-bindings?

* leaky let*-bindings?
@ 2005-02-21  4:57 Julian Graham
  2005-02-21 21:31 ` Kevin Ryde
  0 siblings, 1 reply; 3+ messages in thread
From: Julian Graham @ 2005-02-21  4:57 UTC (permalink / raw)

Hi everyone,
  I'm seeing some behavior from 1.6.7 that has me a bit confused -- if
I specify a binding as part of a let*-expression, e.g. (let* ((a
'foo)) (...)), I find that, occasionally, in a subsequent
let*-expression in the same scope in which I try to create the same
binding, the name resolves to the value from the first
let*-expression.  So that the result of:

  (let* ((a 'foo)) (display a) (newline))
  (let* ((a 'bar)) (display a) (newline))

...would be:

  foo
  foo

...instead of

  foo
  bar

Of course, I haven't managed to reproduce it in such a simple way, so
the ulterior motive of this message is to get you guys to try out the
project that I'm working on, SDOM, a DOM implementation for Scheme. 
I've written a little suite of tests for it, and I find that one test
fails if I run it in sequence with all the other tests but passes if I
run it by itself in a clean environment.  Here's how to reproduce the
problem:

- Download SDOM 0.1.1 from http://www.nongnu.org/sdom/ and install the
module code as per the INSTALL file in the distribution.  SDOM depends
on Oleg Kiselyov's SXML, which Andy Wingo includes as part of
guile-lib, so I feel like a lot of you probably have it.

- Load the tests.scm file included in the distribution (e.g., guile -l
"tests.scm").

- Call the "run-tests" procedure.  The test "documentadoptnode-15"
will fail (possibly along with some other ones) -- that is, the test
wrapper will return #f instead of #t.  Alternately, you can just call
the procedure "documentadoptnode-14" followed by
"documentadoptnode-15."  If you run the tests like this, you can see
the error message it produces.

- Restart Guile and load "tests.scm."  Call the procedure
"documentadoptnode-15."  It should return #t.

When the tests are run in sequence, not only does it looks like the
binding for doc-frag (a variable name that's used in both tests to
store the SDOM representation of a DOM document fragment node) not
only survives going out of scope when documentadoptnode-14 finishes
but retains its original value even after being bound in
documentadoptnode-15 to an empty node.  That is, its value *should*
be:

  (*FRAGMENT* (@ (sdom:owner-document #<procedure #f ()>)))

...but when you run it after documentadoptnode-14, it's:

  (*FRAGMENT* (http://www.w3.org/1999/xhtml:acronym "1230 North Ave.
Dallas, Texas 98551" (@ (@ (@-1 ((sdom:parent-node #<procedure #f
()>))) (sdom:parent-node #<procedure #f ()>)) (title "Yes" (@ (@-1
((sdom:parent-node #<procedure #f ()>))) (sdom:owner-element
#<procedure #f ()>))))) (@ (sdom:owner-document #<procedure #f ()>)))

...which is its value at the end of documentadoptnode-14.

I'm far from being a Scheme pro, so it's quite possible that there's a
problem in my code; I'm not asking for you to debug my project for me,
but I'd greatly appreciate it if someone could download the code and
check it out.  (I'd also appreciate any comments on the API itself,
since I'm trying to shape it into something useful...)

Thanks,
Julian

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

^ permalink raw reply	[flat|nested] 3+ messages in thread