Re: [office-formula] Our next adventure: Types and conversions

[robert_weir@us.ibm.com]

"David A. Wheeler" <dwheeler@dwheeler.com>
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