Our next adventure: Types and conversions

["David A. Wheeler" <dwheeler@dwheeler.com>]

We've discussed syntax.  The next steps I see are:
(1) Discuss types & the rules for their interaction,
(2) Determine how to identify subsets
(3) Define the functions

So, we need to discuss types & the rules for their interaction.
Below are some options & my opinions, but my opinions are
just that: opinions.  I want to know what the group consensus
is, not just my opinion.  We've discussed many of these issues
before, so hopefully what's below is a summary of that.

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.

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.

Thoughts, comments?  These are the key problems
that I saw no obvious agreement on.  I think these are
the key areas for discussion, and if we cannot agree, then
let's see if we can agree to disagree.  There is no
"higher power" we can appeal to; I know of no better
group of people to represent a wide set of spreadsheet
implementations.

(Sorry for the quiet forum.  I got sick for a while, and
when I recovered I had some emergencies to attend to.
Several people have been sending private emails as well.
So, let's quickly get back to finishing this.)

--- David A. Wheeler