I'm going through Paul Graham's ACL book, and noticed something; is
the use of "and" (instead of if with no else) idiomatic lisp?
Something like:
(if (predicate)
(magic happens))
vs.
(and (predicate)
(magic happens))
I understand the mechanics of each, but was wondering what is the
preferred way of doing things (if in fact, one is preferred over the
other).
Also, as I go through my journey of the book, I fully intend on doing
the exercises until they "work", but I'd like to put my working
solutions here and ask for comments. Is that an appropriate use of
the newsgroup? I'll probably indicate in the subject something
obvious so its easily kill-filed.
Thanks
--
Michael Campbell
Michael Campbell wrote:
> I'm going through Paul Graham's ACL book, and noticed something; is
> the use of "and" (instead of if with no else) idiomatic lisp?
>
> Something like:
>
> (if (predicate)
> (magic happens))
>
> vs.
>
> (and (predicate)
> (magic happens))
Actually, you'll want what's behind door #3, WHEN.
(when (predicate)
(magic happens))
Tayssir
+ "Tayssir John Gabbour" <···········@yahoo.com>:
| Michael Campbell wrote:
| >
| > (and (predicate)
| > (magic happens))
|
| Actually, you'll want what's behind door #3, WHEN.
|
| (when (predicate)
| (magic happens))
Yes, mostly. But sometimes I feel that AND is more idiomatic:
(and (< index (length seq))
(elt seq index))
seems more "right" to me. Perhaps because it easily generalizes into
(and (>= index 0)
(< index (length seq))
(elt seq index))
or perhaps it is a result of primarily thinking functionally.
WHEN is certainly much to prefer if you're more interested in side
effects:
(when (lost-on-alien-planet)
(call home))
But I am unable to formulate any firm rule for which of the two is
preferable in the general case.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> Yes, mostly. But sometimes I feel that AND is more idiomatic:
>
> (and (< index (length seq))
> (elt seq index))
>
> seems more "right" to me. Perhaps because it easily generalizes into
>
> (and (>= index 0)
> (< index (length seq))
> (elt seq index))
IMO, this is only ok when the ELT value is being accessed for boolean nature.
e.g., this is ok:
(if (and (< index (length seq)) (elt seq index)) ...) ; OK
this is NOT ok [with me, as if anyone cares]:
(setq frob (and (< index (length seq)) (elt seq index))) ; NOT ok
In this latter case, I have two conceptual reasons for not liking it:
(a) I don't really like the part that is
(setq frob (< index (length seq)))
(b) I don't really like the idea of relying on (and ...) to return
a value other than true. It's more perspicuous, I think, to use
WHEN in that case.
e.g.,
(setq maybe-frob (when (< index seq) (elt seq index))) ; OK
> or perhaps it is a result of primarily thinking functionally.
>
> WHEN is certainly much to prefer if you're more interested in side
> effects:
>
> (when (lost-on-alien-planet)
> (call home))
>
> But I am unable to formulate any firm rule for which of the two is
> preferable in the general case.
It's interesting to see that you rely on a distinction based on
side-effect. I personally don't think that's quite as relevant,
though certainly the present of side-effect is a strong indicator
you've gone the wrong way with AND (see below). But style is a
personal thing, and people don't always agree. At least you have
thought about how to articulate your theory, which I think counts for
a lot in style discussions.
In Maclisp, pre-Common Lisp, PRIN1 and PRINT used to return T (rather
than the printed value). [If anyone is curious, the reason for this
was that in Maclisp, numbers were sometimes allocated in registers,
and to require (PRIN1 3) to return 3 rather than T meant you had to
evacuate the register back to the heap in order to print it... for
small numbers, which were interned [eq-ified], this wasn't a big deal,
but for large numbers, it meant you had to cons needlessly.] And
TERPRI returned NIL. Not sure why it didn't return T. But it led to
the following grossness:
(AND FOO (PRIN1 X) (NOT (TERPRI)) BAR ...)
I think it was the (NOT (TERPRI)) that especially grossed me out because
it _appeared_ to be predicating the idea of not having output a newline,
when really it was just compensating for a bad return value from having
successfully output a newline... But it's definitely yucky. And
(WHEN FOO
(PRIN1 X) (TERPRI)
(WHEN BAR ...))
is _clearly_ easier to understand... at least for me.
Michael Campbell wrote:
> I'm going through Paul Graham's ACL book, and noticed something; is
> the use of "and" (instead of if with no else) idiomatic lisp?
>
> Something like:
>
> (if (predicate)
> (magic happens))
>
> vs.
>
> (and (predicate)
> (magic happens))
>
>
> I understand the mechanics of each, but was wondering what is the
> preferred way of doing things (if in fact, one is preferred over the
> other).
(when (predicate)
(magic-happens))
I try not to use IF unless the else clause is present.
Paul
Michael Campbell wrote:
> I'm going through Paul Graham's ACL book, and noticed something; is
> the use of "and" (instead of if with no else) idiomatic lisp?
>
> Something like:
>
> (if (predicate)
> (magic happens))
>
> vs.
>
> (and (predicate)
> (magic happens))
>
> I understand the mechanics of each, but was wondering what is the
> preferred way of doing things (if in fact, one is preferred over the
> other).
Try to write the code so that it "naturally talks" about the problem
domain. Your example is too abstract to recommend a specific preference.
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++