This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> From: Scott Goehring <scott@poverty.bloomington.in.us> > > No, that's not the real issue. The real issue is that siod's set will > create new global bindings when you set! an undefined variable. Guile > (consistent with the Scheme standard) will not. SIOD's set! is really > closer to LISP's setq in this regard. (SIOD's LISPish heritage is > showing.) Now a word from the language lawyer. R5RS 5.2.1 "Top level definitions" says: Some implementations of Scheme use an initial environment in which all possible variables are bound to locations, most of which contain undefined values. Top level definitions in such an implementation are truly equivalent to assignments. I take this as explicit allowing both the SIOD and the Guile behavior. As for the returned value, 4.1.6 "Assignments" says: The result of the set! expression is unspecified. While 1.3.2 "Error situations and unspecified behaviour" says: If the value of the an expression is said to be "unspecifed," then the expression must evaluate to some object without signalling an error, but the value depends on the implementation. I take this to mean that (set! a (set! b 42)) must execute without error and must set 'a' to a valid value. Of the values mentioned in R5RS, 42 is the most obvious and defensible choice. Guile sets 'a' to #<unspecified>, a value invented for the purpose. A macro to make Guile's set! return the assigned value is occasionally useful and mostly harmless, but it is not really worthwhile to try to emulate SIOD behaviour on undefined variables. (1) The Guile way gives a warning if a variable is misspelled, while the SIOD way gives a nasty bug. (2) It is pretty easy to take a SIOD script and add a few (define foo #f) expressions to get a script that works in both Guile and SIOD. If Guile is small, fast, and powerful enough to be attractive in itself, this should be no big problem. -- --Keith This mail message sent by GNU emacs and Linux. Food, Shelter, Source code.