Re: why undefined return values?

[mstachow at alum dot mit dot edu]

PILCH Hartmut wrote:
> 
> > But the other point to observe is that internally, the implementation
> > of your `set' above (maybe you meant `setq') would have to take measures
> 
> no:  (set sym val)
> available at least in ELisp.  sym is a variable whose value is a symbol,
> which is assigned the value.  This is more 'basic' than setq, in the sense
> that it is easier to derive setq from it than vice versa.  (Maybe we
> should distinguish 'logically basic' and 'implementationwise basic')

I'm not very familiar with elisp; I was reading what you wrote at a pseudocode
sort of level. That's certainly not what `set' does in Common Lisp for instance.

> I assume that set! reads both the variable name/address and the new value
> from its parameter stack.  set/setq only has to return a pointer to either
> the variable or the stack. 

Maybe you could write the interpreter that way, but Guile is based on returning
values, not pointers to values, so it would have to be dereferenced. Anyway,
I am more concerned about conceptual overhead; I think getting and setting
make more sense as separate concepts.

> Any performance penalty would occur only when  a calling function copies this
> information into its own space to make use of it.

> > 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.
> 
> set and setq return the new value, 

Sorry for the misunderstanding.

> and for the scsh code I submitted here, certainly
> 
>        (define match #f)
>        (cond
>         ((begin (set! match (regexp-search ....)) match) #t)
>         ...
>         )
>        (if match
>         (display (match:substring match 1))
>         (display "not found")
>         )
> 

Well, the way I'd write that in normal Scheme style is

(let ((match (regexp-search)))
    (cond 
      (match #t)
       ....
    )
    (if match
       (display (match:substring match 1))
       (display "not found")))

Am I missing a reason why this is bad? It certainly looks more readable to me.

In Scheme it is generally preferred to use lexical scoping constructs to
introduce new bindings rather than mutation.


> as I had hoped.
> 
> > 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.
> 
> I would hope to have a set/setq available also.

I'm not convinced it's useful enough to put in the Guile core. The way
most people use Scheme it's not really necessary, and most other implementations
do not have this behavior.

> Maybe first as a macro that works.  Unfortunately I have not yet mastered
> Scheme macro writing. R5RS offers a very sophisticated formal description,
> but I haven't found a tutorial.  Maybe a definition of setq could get me
> started.  I would be interested in something general that works on
> standard Scheme.

Someone already posted setq as a define-syntax macro, which should work in
all R5RS implementations.

 - Maciej