Date: Sun, 9 May 2010 20:40:36 +0200 From: [email protected]

I still see the same old contradiction -- the code does (roughly) the same, and you didn't change the comment in that commit either.

Duh! I have a habit of writing the value to be compared against first, but <'s "less than" moniker presupposes the opposite order. I.e.,     (= 2 x) ; is x equal to 2?     (< x 2) ; is x less than 2? The comment, which uses infix notation, has it right. (The reason I prefer the first order is I find it more readable when a complicated expression is substituted for x. Compare     (= 2 (wibble           (wobble (flob)))) with     (= (wibble         (wobble (flob))) 2) or     (= (wibble         (wobble (flob)))        2) It is more readable to present the simplest expression first, and the simplest expression is usually the one we compare against.) Well, commit [5c7c7193ca] should set things right. Vegard _________________________________________________________________ Få nye Windows Live™ Messenger. http://download.live.com/messenger

Date: Sun, 9 May 2010 22:35:39 +0200 From: [email protected]

Actually, I tend to feel mildly irritated by things like (= 2 ) (which you seem to prefer) -- to me it makes much more sense to preserve the natural language logic of the expression, i.e. "Is equal to 2?", in its programming-language rendering.

I agree that natural syntax matters, since we think in natural syntax. The problem is that many programming statements, especially those in Lisp, have way more levels than do natural sentences. That clumsy matching and type conversion you pointed out was more or less the Elisp equivalent of the following passage:     Isn't the proverbial German phenomenon of the verb-at-the-end     about which droll tales of absentminded professors who would begin     a sentence, ramble on for an entire lecture, and then finish up by     rattling off a string of verbs by which their audience, for whom     the stack had long since lost its coherence, would be totally     nonplussed, are told, an excellent example of linguistic     recursion? Except that I actually phrased it in this way:     Isn't an excellent example of linguistic recursion the proverbial     German phenomenon of the verb-at-the-end about which droll tales     of absentminded professors who would begin a sentence, ramble on     for an entire lecture, and then finish up by rattling off a string     of verbs by which their audience, for whom the stack had long     since lost its coherence, would be totally nonplussed, are told? In this case, (eq <good-example> (level (level (level ...)))) seems better to me than (eq (level (level ...)) <good-example>). Like a newspaper story, the former gets to the point before it starts babbling. :) Vegard _________________________________________________________________ Få nye Windows Live™ Messenger. http://download.live.com/messenger

On Sun, May 09, 2010 at 09:20:57PM +0000, Vegard Øye wrote:

...

Actually, I tend to feel mildly irritated by things like (= 2 ) (which you seem to prefer) -- to me it makes much more sense to preserve the natural language logic of the expression, i.e. "Is equal to 2?", in its programming-language rendering.

I agree that natural syntax matters, since we think in natural syntax.

The problem is that many programming statements, especially those in Lisp, have way more levels than do natural sentences. That clumsy matching and type conversion you pointed out was more or less the Elisp equivalent of the following passage:

    Isn't the proverbial German phenomenon of the verb-at-the-end     about which droll tales of absentminded professors who would begin     a sentence, ramble on for an entire lecture, and then finish up by     rattling off a string of verbs by which their audience, for whom     the stack had long since lost its coherence, would be totally     nonplussed, are told, an excellent example of linguistic     recursion?

Except that I actually phrased it in this way:

    Isn't an excellent example of linguistic recursion the proverbial     German phenomenon of the verb-at-the-end about which droll tales     of absentminded professors who would begin a sentence, ramble on     for an entire lecture, and then finish up by rattling off a string     of verbs by which their audience, for whom the stack had long     since lost its coherence, would be totally nonplussed, are told?

In this case, (eq <good-example> (level (level (level ...)))) seems better to me than (eq (level (level ...)) <good-example>).

Not to me; and as the 3rd of your original lisp examples in a former e-mail shows, you can use indentation to make it a non-issue even from your-definition-of-readability point of view. It's how you _think_ about things what really matters here, not how you express something in a natural language. The two, albeit related, are distinct -- that's why I used the word "logic", not "syntax". The very example of the error you made shows how unhelpful going against one's thinking while writing in a language is. Štěpán

On Mon, May 10, 2010 at 12:21:39PM +0000, Vegard Øye wrote:

...

The very example of the error you made shows how unhelpful going against one's thinking while writing in a language is.

Granted. I guess I started doing it this way when converting a bunch of `case' forms to `cond' forms (since `case' is not available in plain Elisp), e.g.,

    (case variable          (cond       ('foo                  ((eq 'foo variable)        (wibble))              (wibble))       ('bar           =>     ((eq 'bar variable)        (wobble))              (wobble))       (t                     (t        (flob)))               (flob)))

The repeated "variable" is just line noise in this example, hence I put it last.

No; it's just the same as with other examples -- `variable' has a meaning, and I would put it first (the redundancy is irritating, but I don't see how inverting the argument order improves that). [Line noise are the quotes in the `case' form, BTW.]

Apparently, "Yoda conditions" are rather unpopular in infix languages. Maybe they should be avoided in prefix languages as well.

No idea about either of those statements. From my very limited code-reading experience, the first one might be true. As for the second one, "makes sense" is more important for me than "everybody does it", although it might make sense to obey certain conventions, esp. when collaborating with others. Fortunately, conventions generally tend to make sense -- in code writing, that is; certainly not in a lot of other areas of human activity. Štěpán

Vegard _________________________________________________________________ Få nye Windows Live™ Messenger. http://download.live.com/messenger