"David A. Wheeler" <>
wrote on 05/21/2006 10:02:11 PM:
>
> First: Which types?
> All seem to agree that implementations may add new types,
> but that certain types are so common that specifying them
> is valuable for interoperability. All seem to agree that
> Text (String) and Number are two of those types.
> Many implementations have a "Logical" type that is
> _distinguishable_ from Number, while in others, a logical
> value is simple a Number that is 0 or 1 (with nonzero treated
> as true). References are also another type. There are
more, but
> let's start there. I see several options:
> A. Logical is REQUIRED to be distinct from Number.
> Inconsistent with OOo, Lotus 1-2-3, & many others.
> B. Logical is REQUIRED to be the same as Number:
> Inconsistent with Excel, Gnumeric.
> C. "Logical" used as a notional type (so that we can easily
> identify functions that take/return logicals), but we
> explicitly permit EITHER of the above.
> I recommend "C". If implementations can co-exist
> with this variance, I think we can too.
How about A, but allow automatic conversion to Number
type? I believe this is different from C, in that the conversion
from Number to Logical would not be automatic.
>
> Next up: how do they interact? In particular: if a function
> expects a Number but gets a Text value, then what?
> A. Text auto-converted to Number. Excel & Gnumeric
> do this. There is a BIG PROBLEM here involving
> locale... a conversion can work in one locale, &
fail
> in another.
> A1. Conversions usually work using the
> "current locale" this is a problem -- the
SAME spreadsheet
> would work in one place and fail in another. Yes,
many
> implementations (e.g., Excel) really do this.
> A2. An alternative would be to save the
> locale of a spreadsheet on creation, and ALWAYS use
that
> "sheet locale" on an automatic conversion.
But note that
> nobody does that, so we have the risk of invention
> without experience.
> B. Text converted to 0. Lotus 1-2-3 does this.
> C. Text converted to 0 if via reference, and auto-converted
> to number if in-line. OOo 2.0 does this.
> D. Text converted to error. Eike thinks this would be safest,
> since it would force spreadsheet authors to notice.
> I know of no one who does this.
> E. Allow some set of the above. Spreadsheet users could
> add VALUE() calls where they wanted conversions.
> One problem: VALUE() doesn't have a fixed locale, it
> uses the current locale (usually). We could modify
the
> definition of VALUE, or create VALUEL(v;locale).
> (Creating a new function as a standards invention
> seems less evil to me, though it's still not ideal.)
> I recommend (E) with "all of the above except A2".
> I'm not sure we want to create VALUEL(), though
> it'd be nice to have.
>
Generally I'd rather give an error than to do something
which has a good chance of being wrong. We've come a long way since
spreadsheets first came about. Back then we programmed in assembler,
and maybe the old C before prototypes, when everything looked like an int.
Now we've generally learned that strict typechecking is often a good
thing. But this view is not universally held. What makes sense
for a spreadsheet which is used by non-programmers? We want them
to avoid the common mistakes, but we don't want to force them to work hard
at it.
So, auto-conversion to text in the general case is
dangerous, and I don't mind forcing the user to invoke it specifically
where needed, perhaps specifying a fixed locale, or defaulting to the current
runtime locale.
So, I think I'm suggesting E, without A1 and without
A2. So, an error for a naked use of text in the context of a number,
but allow Value(text;locale) and value(text) to avoid the error.
-Rob
