Re: why undefined return values?

[Maciej Stachowiak <mstachow at alum dot mit dot edu>]

PILCH Hartmut wrote:
>
> Wouldn't it have been easier to define
> 
>         (define set! (lambda (var val) (set var val) #f))
> 
> This btw also shows that not only setq is more basic than set!, but
> set is the most basic of all.

First, the fact that you can more easily ignore a return value than
add one does not prove that having the return value is "more basic".

But the other point to observe is that internally, the implementation
of your `set' above (maybe you meant `setq') would have to take measures
to save the old value before doing the set and then return it. So you
would pay the (admittedly small) performance penalty for the return
value
behavior even when you don't want it, if `set!' is implemented in terms
of `setq'.

Another reason I think making `set!' have a return value is bad is that
it's not obvious whether it should return the old value (as you propose)
or the new value. The latter certainly seems like a more logical
choice for the return value of an assignment.

> Sorry to have brought up this debate.

I don't think it was bad to bring this up. I can see cases where
having set! return a value is convenient. However, for the reasons
above, and in order to make it easier for users to write
standard-conforming code, I don't think `set!' should behave that
way.