any? vs. some?

[kmp@MIT-MC.ARPA]

    Date: Sat, 17 Sep 83 15:12:25 EDT
    From: Stephen Slade <Slade@YALE.ARPA>

    This may have been discussed some time ago, but the use of ANY? 
    for an existential quantifier violates conventional usage in logic.
    There, ANY? would correspond to the universal quantifier EVERY? or 
    ALL?, and the existential quantifier would be SOME?

    The vernacular usage is ambiguous.  It just appears that T is 
    coming down on the side opposed to the logical usage.

The choice of names for those operators was discussed extensively
between Jonathan and myself when bringing up the original T system
a couple summers ago.

I'm not sure what you mean by ANY? corresponding to the universal. It
only does if you introduce a NOT somewhere, and you can represent
universal with existential any time once you allow NOTs, so that's a
tricky kind of argument to make.

In any case, the rationale didn't take logic into account but for making
sure that both kinds of operations were represented. The real
considerations were our built-in English linguistic intuitions...

The names had to be either ANY/EVERY or SOME/ALL. These are the English
symmetric pairs. The LispM uses SOME/EVERY, which is an asymmetric
mish-mash that makes it hard if you know the name of one operator to
remember the name of the other.

SOME tends to carry a more "plural" sense to it than ANY does. People
seeing code like "(IF (SOME ...) ...)" may want to read it "If there are
some things ..., then ..." where it should perhaps be read "If there is
some thing such that ..., then ...". It may feel like more than one is
necessary to satisfy the test.  In the case of ANY, it's harder to
abuse. "(IF (ANY ...) ...)" is hard to read in any other way than "If
ther is any thing that ..., then ...". I believe this is why we
eventually decided against the SOME/EVERY pair. ANY tends to force the
user to read it as possible that there might be exactly one match. This
is subtle, but important in informal code correctness verification.

There might have been other reasons for this particular choice as well.
This is all that comes to mind offhand. But in general, these sorts of
arguments about how people would read code, including phonetic,
syntactic, and semantic views, were what went into the naming of many of
the operators. We tried to place a very high value on the names of
things we knew people would be using day to day for years to come.
Anyway, I hope it's at least enough to let you know we didn't make the
decision haphazardly.

-kmp