unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Julian Graham <joolean@gmail.com>
Subject: leaky let*-bindings?
Date: Sun, 20 Feb 2005 23:57:05 -0500	[thread overview]
Message-ID: <2bc5f821050220205776bd9ec3@mail.gmail.com> (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


             reply	other threads:[~2005-02-21  4:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-21  4:57 Julian Graham [this message]
2005-02-21 21:31 ` leaky let*-bindings? Kevin Ryde
2005-02-21 22:26   ` Julian Graham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2bc5f821050220205776bd9ec3@mail.gmail.com \
    --to=joolean@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).