freenode/#clim - IRC Chatlog
Search
6:42:44
beach
I guess I should have warned you that when I am in review mode (code, papers, etc), I switch to becoming very direct and "dry", which may come across as inconsiderate and rude. I don't mean it that way, though.
6:46:43
beach
Yes, I figured you are a grown man so you can handle it. With some of the more inexperienced people I deal with, I have to tread more carefully.
6:55:09
beach
It says, that WHEN and UNLESS should be used for one-branch STATEMENTS, in other words, in a context where the value is not used. The LET thing is similar in spirit. The Common Lisp HyperSpec says that WHEN and UNLESS return NIL by default, so the compiler doesn't mind if I write (setq x (when <condition> <value>)).
6:56:26
beach
Similarly, (in my opinion, of course) (LET (X) ...) and (LET ((X NIL)) ...) send different messages to the person reading the code.
6:57:55
beach
Yes, when it is used for value. Or (if <condition> <value> '()) if the value is supposed to be a list.
6:59:24
beach
NIL means "false" or "default value", () means an empty parameter list, '() means an empty list.
6:59:52
slyrus
the example on page 13 isn't exactly what you said. I agree that (if (numberp x) (cos x)) is bad, but only because (when ...) is better for that example.
7:01:24
beach
Well, if you WHEN that way, either you are not using the value of (COS X) in case the condition is true, or else you are not respecting the rule that WHEN is only used as a STATEMENT.
7:01:35
slyrus
Meaning is subjective and can be influenced by our existing beliefs. I think of nil first and foremost as an empty list. That just happens to be a nice way of expressing falsity.
7:02:49
beach
Style rules must be about general rules as opposed to personal belief, at least if you believe that communication between people is an important aspect of coding style.
7:03:29
beach
You are obviously entitled to declare that your rules are better than those of Norvig and Pitman.
7:06:20
beach
On page 13, you will also find the rule that I am applying for the EQL vs = thing. The general rule says "use the most specific construct that will do the trick" (or something to that effect).
7:07:09
beach
According to the same rule, it is better to use (1+ x) than (+ x 1), better to use (incf x) than (setf x (1+ x)), etc, etc.
7:08:22
beach
So in this case, when I (as a reader of the code) see =, then I already expect numbers, but when I see EQL, I don't know until I read the arguments, and even then I might not know.
7:10:48
slyrus
no, you're right about the = thing. I just question whether the extra six characters ( two parens, a space and nil) are worth it for the let thing. But, as you may have noticed, I updated the code in the PR to match your style.
7:11:48
slyrus
If we're gonna jam together, we should probably all at least be in the same key, absent strong motivation to the contrary.
7:13:34
beach
Anyway, I just wanted to explain that these are not some rules I pulled out of a hat, nor are they rules that I just invented myself.