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]

set! (The GIMP! By gum, I forgot all about it!)


>   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.

I have to agree that I always liked the way (setq) used to return
the value in LISP and I see it as only bloody-mindedness on the part
of some purist that guile forces everything to #<unspecified>
(probably more the fault of R4RS than guile though). It would be nice to
be able to use (set!) in (cond) (and) and (or) expressions rather
than dick around with local variables. While we are at it I find
(while) far more intuitive than (do) especially the stupid way that
(do) specifies an expression that must be true to LEAVE the loop rather
than to KEEP GOING. This is different to for() and while() in C.

I must presume that a lot of R4RS and R5RS was written by people that
just hated C programmers.

Anyhow, there isn't much to be done at this late stage because even
if guile did return a sensible value from (set!), no one could depend on
what that value was and remain portable to other scheme implementations.

> 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.

agreed

>   (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.

How about a system that catches the error from the undefined (set!),
then writes out to an extra file "(define foo #f)" based on the
error that it caught, then issues a (load) on the extra file (which will
be able to alter the top level bindings). When the script is finished
executing, the extra file of (define)s can be tacked onto the top of
the script file and the resulting file will work in both guile and SIOD.
The script translation can be silent and automated!

	- Tel