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?


Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> PILCH Hartmut <phm@a2e.de> writes:
> 
> > Having read r4rs and scsh-manual.ps and started to write scheme programs,
> > I am desperately looking for something like (setq a 1) that will return
> > the value.  (set! a 1) is quite useless in most programming contexts that
> > I am used to think in, coming from (Common and Emacs) Lisp.
> > 
> > I can't see any design advantage in providing unspecified return values
> > and I expected to find a heated debate on this in some FAQ, but I didn't.
> > 
> > Should I go back to Lisp and not bother with Scheme any longer, or could
> > there possibly be some good reasoning behind this? 
> 
> 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.

quite.  but if you still *want* to have setq, that's very easy:

(defmacro setq (var val)
  (let ((tname (gensym)))
    `(let ((,tname ,val))
       (set! ,var ,tname)
       ,tname)))

 -or-

(use-syntax (ice-9 syncase))

(define-syntax setq
  (syntax-rules ()
    ((setq var val)
     (let ((tmp val))
       (set! var tmp)
       tmp))))

> Also, while Scheme is mostly functional, it also supports imperative
> programming, through set!, set-car! and set-cdr!.
> 
> It is a good idea to try to avoid these altogether.  It's likely that
> such operations won't be as efficient as purely functional code in
> future Scheme compilers and interpreters.

well, I would change it to "it's a good idea to avoid set!
altogether, except when used on top-level bindings".  set-car! and
set-cdr! look quite innocuous to me style-wise, but the performance in 
the presence of a generational GC might suck.

--mike

-- 
Those who do not learn from history, loop.

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