Re: why undefined return values?

[Jim Blandy <jimb at red-bean dot com>]

> > > I'm not aware of the precise reasoning, but it seems to me that the
> > > idea of the language construct (set! VAR VAL) is to alter the value of
> > > VAR.  It doesn't seem to be a good idea to add further functionality
> > > to this construct since that mixes concepts.
> 
> This is what I had expected to find a flamefest about somewhere.
> I have lots of
> 
>       (let (eof match str)
>        (if
> 	(and 
>            (not (setq eof (eof))
>            (setq match (find-match regexp))
>            (setq str (car match)) 
>           )
>          ...
>         )
> 
> type constructs in my programs and it seems quite unnatural to unmix the
> two concepts, just as it would be to unmix the 3 functions of `let':
> (1) bind variables, (2) evaluate a body and (3) return a value.

You're correct that there is ample precedent for assignment operators
that return a value, even in near relatives like Common Lisp and
Emacs Lisp, not to mention the C language family.

The Scheme authors decided not to specify whether set! returns a
value.  It's explicitly allowed for Scheme systems to return anything
they please, including nothing.

So the question is, what makes the best tool?

I used to write a lot of Emacs Lisp code, and I certainly used the
value of setq a lot; it made for quite concise code in some cases.
But the idea that set! is an action, not something that computes and
yields a value, also appeals to me.

My personal preference is that set! return no value.  But the decision
is up to Guile's maintainer.



I've heard it argued that set! should return no useful value because
that encourages people to write code which will run properly on other
Scheme systems.  But it's so hard to write portable code in Scheme
that actually does anything anyway that you're practically forced to
use local extensions --- just to report an error, for example.  So
this argument doesn't carry much weight with me.