Rationale behind conversion of a nil prefix arg to numeric 1

[Florian v. Savigny]

Hi there,

I've written one or two functions whose invocation I modeled on Unix
file permission bits (where a single digit is always unambiguously
either 1, 2 and 4 or some sum of them; thus, possible values are 1, 2,
3 (1 + 2), 4, 5 (1 + 4), 6 (2 + 4) and 7 (1 + 2 + 4)) because I felt
it was quite a nifty way of passing a command zero, one, two or three
"flags" at once via an optional prefix argument. (Apart from the fact
that it's quite easy to forget which number means which flag.)

Naively, I used the numeric conversion of the prefix arg, i.e.

   (interactive "p")

which passes the prefix arg converted to a number. However, if I call
the function with no prefix argument, which is, expectedly, nil in raw
form, it converts this to the number 1. (This is what
`prefix-numeric-value' does, as explained in the docstring.)

While I understand that this is how it is done, I am quite puzzled
about the logic behind this. It would seem intuitive to me to convert
nil to either the number 0 or, again, nil, but never to the number
1. And practically, converting nil to 1 has the consequence that
calling the command with no prefix arg:

   M-x command

is exactly the same as calling it with a prefix arg of 1:

   C-u 1 M-x command

because the prefix arg converted to a number is 1 in both cases, which
reduces the number of possibilities of calling the command by one.

I can circumvent this (and get the behaviour that I would expect) by
writing the function with

   (if current-prefix-arg (prefix-numeric-value current-prefix-arg))

in an explicit interactive list, but I am still wondering about the
rationale of representing nil as the number one. Does this make sense,
or is it useful, in some way?


Thanks for any enlightenment!

Florian




-- 

Florian von Savigny
Melanchthonstr. 41
33615 Bielefeld