On 9/8/06, David A. Wheeler <> wrote:
> I think it would be DISASTROUS to spec something we KNOW
> is not true, and will NEVER become true. Better to make it
> implementation-defined... which is in fact what we do.
Hmm. Basically, you are suggesting to write in the spec something
like: "Implement this function how you want" ? I'm not sure if we'll
manage total compatibility that way, but ah well, seems like there
isn't any better option.
Sooo.
Bot A and non-A treat numbers as numbers.
If the implementation doesn't have distinct logicals, then logicals
always get treated the same as numbers.
If the implementation supports logicals, A version treats them as 1
and 0, non-A is implementation specific.
As for strings, the behaviour is implementation-specific. A-version is
never allowed to ignore it, it must somehow convert the string to a
number - either parse the number, or just use 0. Non-A version can
either convert the string to a number, or ignore the string entirely.
All these functions must behave in the same way for one implementation
- ie., if SUM treats logical/strings in some way, COUNT, AVERAGE, ...,
all must treat them the same.
Are the rules regarding these functions good enough now ? :)
Also, where to write them ? I think it'd be bst to write these in some
section somewhere, and in each related function, point the reader to
that section, so that we don't have to copy-paste these rules 20
times.
/ Tomas