[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CL package serious deficiencies
From: |
Stefan Monnier |
Subject: |
Re: CL package serious deficiencies |
Date: |
Fri, 10 Feb 2012 13:24:00 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
>> I've used incf occasionally, but don't find it terribly important.
> I find it adds readability, since you don't have to see that
> "(setq foo (1+ foo))" has the same `foo' both places.
No disagreement (I also dislike such duplication, which is why I insist
on using (set (make-local-variable 'var) val)), I just don't find it's
often enough important (in my experience it's not used that often, and
most times it's used, it's used on locally-bound variables with short
names).
This said, if/when we have `setf', then there's no reason not to have
`incf'.
>>> `plusp'?
>> Never used it. (> n 0) is no shorter than (plusp n) and is just as
>> clear, so I really don't see the benefit.
> Again, I think it's usually more readable, because (as with `zerop')
> it's immediately obvious what the condition is. Especially with longer
> parameters:
> (plusp (1+ (foo-thing-that-computes-something)))
> vs
> (> (1+ (foo-thing-that-computes-something)) 0)
that's because you write it wrong:
(< 0 (1+ (foo-thing-that-computes-something)))
aka
(< -1 (foo-thing-that-computes-something))
aka (assuming it's integer)
(<= 0 (foo-thing-that-computes-something))
> I think the `-if' and `-if-not' help with reading comprehension, because
> you're signalling in the function name what you mean to do, and you
> don't have to read the predicate as thoroughly. And the predicate can
> be written clearer, too. If you don't have both forms, the predicate
> often tends to look like `(lambda (foo) (not ...))', which makes my
> brain hurt.
That's just a question of habit, really.
[ You might prefer "delete-if (¬ ∘ pred) list", of course. ]
Stefan
- Re: CL package serious deficiencies, (continued)
- Re: CL package serious deficiencies, John Wiegley, 2012/02/09
- Re: CL package serious deficiencies, Stefan Monnier, 2012/02/10
- Re: CL package serious deficiencies, Juanma Barranquero, 2012/02/10
- RE: CL package serious deficiencies, Drew Adams, 2012/02/10
- Re: CL package serious deficiencies, Stefan Monnier, 2012/02/10
- RE: CL package serious deficiencies, Drew Adams, 2012/02/10
- Re: CL package serious deficiencies, Lars Ingebrigtsen, 2012/02/10
- Re: CL package serious deficiencies,
Stefan Monnier <=
- Re: CL package serious deficiencies, Lars Ingebrigtsen, 2012/02/10
- Re: CL package serious deficiencies, Johan Bockgård, 2012/02/10
- Re: CL package serious deficiencies, Helmut Eller, 2012/02/10
- Re: CL package serious deficiencies, Stefan Monnier, 2012/02/10
- Re: CL package serious deficiencies, Lars Ingebrigtsen, 2012/02/10
- Re: CL package serious deficiencies, Helmut Eller, 2012/02/10
- Re: CL package serious deficiencies, Stefan Monnier, 2012/02/12
- Re: CL package serious deficiencies, Helmut Eller, 2012/02/12
- Re: CL package serious deficiencies, Stefan Monnier, 2012/02/12
- Re: CL package serious deficiencies, Helmut Eller, 2012/02/12