This is the mail archive of the guile@sourceware.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]

Re: why undefined return values?


I wrote
> >
> > Wouldn't it have been easier to define
> > 
> >         (define set! (lambda (var val) (set var val) #f))

This 'set!' deviates a little from the required behavior.  It would have
to be used like

	    (set! 'a 1)

I guess the real set! would in this case have to be a macro.

> 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')

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

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.  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, 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") 
	)

using the old value #f wouldn't allow me to eliminate the ugly 

  	(begin (set! ...))

	((setq match (regexp-search ...)) #t)
	
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.

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.

--
phm



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]