Subject: Re: Newbie Q: let/setf and testing
From: Erik Naggum <erik@naggum.no>
Date: 1999/08/29
Newsgroups: comp.lang.lisp
Message-ID: <3144908662537112@naggum.no>

* Andrew Cooke
| I have two functions, which should be executed in turn (the second takes
| the results of the first as an argument) and, if both are non-nil, I want
| to do something with the results of the second.  That sounds obscure, but
| it's quite common, at least in C-like code (sorry! :-)
| 
| if (r1 = f1(a, b, c) && r2 = f2(r1, d, e)) {
|  ...
| }

  what happens to r1 and r2 in the body and after it?

| Is there a better way, and if not which of the two above is considered
| better style?

  I think I might have used non-local returns like this:

(block nil
  (let* ((r1 (or (f1 a b c) (return)))
	 (r2 (or (f2 r1 d e) (return))))
    ...))

  note that this idiom is a lot more powerful than to just testing for a
  boolean return value.  being able to return from a function or block
  anywhere within it can be used to create both readable and efficient
  code, but it will be out of reach for C programmers and others who think
  that non-local returns are bad or somehow a different kind of language
  construct (which it is in C).

| On the other hand, the "setf" seems gratuitous given my (minimal)
| experience of functional programming.

  well, it isn't lack of SETF or SETQ that makes a program functional, it's
  the lack of side effects.  this is the same argument as GOTO, which some
  people believe they can't use in structured programs.  if you assign a
  value to a variable once and you don't use the binding, what you're
  looking at is a failure of the language to capture the binding forms you
  need, just as GOTO may be necessary to write well-structured programs in
  languages that don't support the control structures you need.

  I have a problem with the "false purity" of various approaches to writing
  code.  it's as if people would cringe at code that is semantically in the
  style they want, and embrace code that is not, because some syntactic
  aspect of the code violates some prejudice that makes it "impure".  e.g.,
  you can write worse spaghetti code with a lot of boolean variables that
  try to do what a few well-placed goto's could have done very elegantly.
  you can write dysfunctional code (pardon the pun) in a functional style.

#:Erik
-- 
  save the children: just say NO to sex with pro-lifers