Re: constant `e'

[Daniel Brockman]

Stefan Monnier <address@hidden> writes:

>> Incidentally, I also think `(not (null n))' looks better than `n'
>
> Please, it's not the same thing: (not (null 2)) != 2

But this is exactly why `(not (null n))' is clearer:
It makes it immediately clear that the value of `n' is
not used for anything (other than testing for nil).

> Code is a way to communicate, so if you write (not (null N)) instead of N,
> the reader will have to wonder:
> - is this a beginner who doesn't realize who could/should have just used N?
> - or is it an experienced programmer who just wants to tell me something
>   about his intention?
> - or is it really that the code needs the value converted
>   to a nil/t "boolean"?

One can ask many interesting questions about the author of a
piece of code.  Other examples include,

 - Did a lazy programmer who couldn't be bothered to put
   `(not (null ...))' around this expression write this?

 - Was it an experienced programmer who left it out on
   purpose because the value is really used in some way?

 - Is is probable that the author likes coffee?

Another thing one can do with code is to forget about the
author for a minute and focus on reading the code instead.

Reading `(not (null n))', its meaning is obvious ---
for crying out loud, it's almost an English phrase.

> Also, the compiler will have to work extra hard to try and figure out
> whether it is safe to optimize it away or not.  If it's more work for the
> compiler, it's probably more work for the human reader as well.

I doubt the valitidy of that.  The purpose of high-level
languages is to make code easier for humans to read at the
expense of making it harder for computers to execute.
This seems to fundamentally contradict your statement.

-- 
Daniel Brockman <address@hidden>