This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: problem with set!
- To: "Otto, Marcus" <Otto_Marcus at ph-ludwigsburg dot de>
- Subject: Re: problem with set!
- From: Per Bothner <per at bothner dot com>
- Date: 21 Oct 2000 09:34:10 -0700
- Cc: kawa at sourceware dot cygnus dot com
- References: <39F1DAF4.32510.9351C2@localhost>
"Otto, Marcus" <Otto_Marcus@ph-ludwigsburg.de> writes:
> when I replaced my old Kawa with the new Version, I found some funny
> behavior of the set!-command. It sets unbound variables.
> ...
> with respect to the last paragraph of 5.2.1, kawa should either issue
> another error for the set!-command or no error at all, i.e. a is
> bound from the begining.
You would be correct if the standard said "locations, most of which
contain unspecified values". The term "unspecified" is defined in
1.3.2. However, it says "undefined". I am quite certain that the
behavior of Kawa matches that of the described "some implementations"
- it certainly matches Common Lisp and Emacs Lisp. I am equally
certain that the behavior of Kawa is conformant to R5RS.
Now I too would prefer the implementation to signal an error where
you describe. However, that is difficult if I also want to
support Common Lisp and Emacs Lisp semantics - and interoperability
between these languages. Not impossible, but tricky, and I haven't
come up with a design I am happy with. (I.e. has teh desired sematics
without being excessively complicated. Of teh current implementation
is also quite kludgy when it comes to top-level environments.)
> My question now is: is there an esay way to get back to the behavior
> of the old kawa in this case? I do not use elisp or commonlisp, just
> scheme.
>
> I found a commented line in gnu.expr.SetExp.java where an
> UnboundSymbol-exception is thrown:
>
> if (bind != null)
> env.put (name, new_val);
> else
> env.define (name, new_val);
> // throw new UnboundSymbol (name);
>
> I changed the last two lines to
>
> // env.define (name, new_val);
> throw new UnboundSymbol (name);
>
You also have to handle the case of compiled code.
> This seems to work fine for top-level assignments, but does not help
> with set!-commands in the <body> of a lambda or so.
There are two kinds of set! commands in the body of a lambda: Those
that refer to lexically bounds varibles, and those that refer to
bindings in the lobal environment. Your change will effect the
latter (as it should), but not the former (which is also correct).
> BTW: Is it possible to refer to the extended environment of a <body>
> from within that <body>, i.e. for example where
>
> (lambda (x)
> ((this-env) 'x))
>
> is the same as
>
> (lambda (x) x)
No. Not without turning this-env into something very magical.
(Notice it has to be handled at compile time, since there is
no run-time binding object for x.
--
--Per Bothner
per@bothner.com http://www.bothner.com/~per/