[pro] (values) for for-effect functions

[Daniel Weinreb]

In case these terms are too old for anyone to know
them, we used to use the phrase "for effect" to
mean a function that was called for the sake
of its side-effects, versus "for value" when it was
called for the sake of its returned value. (Actually
I'm not sure I remember what we called a function
with both properties.)

In some code I have seen, the author of the code
has written (values) at the end of an implied-progn
body.  The purpose, pretty clearly, is to signal
the reader of the code that the function was
purely for-effect, i.e. that the returned value
does not mean anything.

This is mostly stylistic.  In most cases, returning
"nil" means the same thing as returning no values,
i.e. (values).  The only situation where it makes
any difference, as far as I know, is when
multiple-value-list is being called, and that's
used very, very rarely.

The question is, is it good style?  That is, ought
we consider it something to be recommended?

The pro is that it presents clear information to
the reader of the code.  Merely not putting
anything at the end of the implied progn means
that the value of the last function called is
the returned value, and the reader of the
code might think that was on purpose.

On the other hand, having a (values) at the end
does not actually prove that the function
does not have any meaningful value, since a
"return" within the function could return
a value (or many values).

 From a purely emotional/historical point of
view, I am not used to seeing these (values)
forms, and they seem somewhat ugly and
verbose.  But that's just based on my own
experience and should not carry much weight.

I'd like to write in our programming standards
either that they should be used, or that they
should not be used.  I think it's suboptimal
for them to be used in some places and
not others, since the inconsistency could lead
a reader of the code to draw wrong conclusions.

What do people think?

-- Dan