chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Binding identifiers with set!


From: felix
Subject: Re: [Chicken-users] Binding identifiers with set!
Date: Tue, 14 Oct 2003 00:13:17 +0200
User-agent: Opera7.11/Linux M2 build 406

On Sun, 12 Oct 2003 10:19:49 +0100, Category 5 <address@hidden> wrote:

In <address@hidden> on
comp.lang.scheme, Anton van Straaten pointed out that set! can be used
to introduce new bindings in Chicken:

% csi
; This is the CHICKEN interpreter.
; Version 1, Build 17 - netbsd-gnu-ultrasparc
; (c)2000-2003 Felix L. Winkelmann
foo
Error: unbound variable: foo
(set! foo 1)
foo
1


This clearly doesn't jive with R5RS (5.2.1):

At the top level of a program, a definition

(define <variable> <expression>)

has essentially the same effect as the assignment expression

(set! <variable> <expression>)

if <variable> is bound. If <variable> is not bound, however, then
the definition will bind <variable> to a new location before
performing the assignment, whereas it would be an error to perform a
set! on an unbound variable.

From a language-lawyerly point of view, "it would be an error" allows
an implementation to do whatever it likes. So this is strictly speaking
not a violation of R5RS.


How do people feel about this?  I find the behaviour a bit worrying, as
it amounts to the omission of a basic form of error checking supported
by R5RS as well as every other implementation I'm aware of.  I can
imagine situations where this would bite.

Yes, I agree with that. It makes finding bugs harder.


My first choice would be to see set! changed to support the more
restrictive semantics, but failing that, I think the current behaviour
should be explicitly documented in the "Deviations from the standard"
section of the manual.


Changing the semantics of `set!' is currently not easy to fix. But I have
to think about that some more...
I'll document the behaviour int the manual. Thanks for the suggestion.


cheers,
felix





reply via email to

[Prev in Thread] Current Thread [Next in Thread]