Re: [office-formula] New type: Integer

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

I wrote:
> > I've added a new pseudotype, "Integer".  Please use it instead of Number
> > when you really expect or produce integers.  If it's a function's input, please
> > identify the function conversion operation (often INT),

Andreas J. Guelzow:
> If the required type is Integer, shouldn't one get an error if the
> specified argument is not an Integer? I think the specs somewhere that
> if incorrect types are used, the function must return an error.

I don't agree.  I believe ALL spreadsheet applications have, since
VisiCalc on down, automatically converted non-Integers
into integers in these cases.  Since it's 100% common, I expect that many
documents depend on it, and all we'd do is break many documents that
work today.   Auto-conversion isn't insane, in fact it's very convenient
to users, as long as we clearly DEFINE that conversion as
part of the semantics of the functions.  The problem has been that while
it's common, and people depend on it, it's not well-documented.
At the least, I think MANDATING failing on non-integer would just
cause people to avoid using the specification at all.

Anyway, I don't think we should consider it a type error.
There's no separate true "type" called Integer, it's still just a Number.
This is merely a pseudotype - it's an existing type (Number) with an additional
constraint/property.  And as with other pseudotypes, we can choose what
conversion happens when a function expects the pseudotype.  The pseudotypes
are a useful way of documenting similar conversions in similar circumstances.

But I'm happy to discuss this.  Here are some alternatives, too:
* One option might be to PERMIT applications to "fail on non-integer".
   That should probably be some sort of calculation setting,
   so that we can handle ordinary documents that EXPECT conversions
   to integer.  But I suspect that this setting would never be used,
   and we should only define settings that are important for use.
* Any user can force that today with IF(INT(X)=X; X; #VALUE!).
* We could even define a function that did the above, e.g.,
  REQUIREINTEGER(X).  Adding functions is much lower risk, since people
  who don't use the function have their formulas work "as expected",
  and there's no distributed performance cost from checking a new
  and unused calculation setting. A calculation setting
  that must be checked on EVERY use of an integer
  has a much more distributed effect on performance.

If you think "failing on non-int" is an important use case,
I'd prefer defining a new function like REQUIREINTEGER.
Lower risk, & it makes upgrading much less painless.
Thoughts?

--- David A. Wheeler