Forcing string comparisons, or When is "0" not 0?

[Kay C Lan]

On Fri, Oct 16, 2015 at 7:42 AM, Mark Waddingham <mark at livecode.com> wrote:

> I pondered 'is exactly' for the 'is really' semantics... I'm wondering
> whether 'is strictly' is perhaps most appropriate


I've come to this topic late but I'm wondering if all these language
additions aren't making it all the more complex. What about an alternative
approach of using a property to turn 'strictness' on or off, in much the
same way as caseSensitive is used. Although instead of true or false the
'strictCompare' property may have to be tri-level and obviously default
back to 0 (highest level of coercion) at the end of a handler. The benefit
is that you don't have to remember all those subtle syntax variations.

set the strictCompare to 0 --current default level of coercion
put 1 = "1.0" --true
put 1 = 1.0 --true
put 0.1 = "0.1" --true
put "1.0" is a number --true
put "0.1" is a number --true
put "1.0" is an integer --true
put "0.1" is an integer --false
put "THIS" = "this" --true

set the strictCompare to 1  --strings are strings, numbers are numbers, but
values are coerced
put 1 = "1.0" --false - number vs string
put 1 = 1.0 --true - value is the same
put 0.1 = "0.1" --false number vs string
put "1.0" is a number --false it's a string
put "0.1" is a number --false it's a string
put "1.0" is an integer --false it's a string
put "0.1" is an integer --false it's a string
put "THIS" = "this" --true *  --basic value is the same

set the strictCompare to 2 --by-passing all type-coercion
put 1 = "1.0" --false - number vs string
put 1 = 1.0 --false - not exactly the same
put 0.1 = "0.1" --false number vs string
put "1.0" is a number --false
put "0.1" is a number --false
put "1.0" is an integer --false
put "0.1" is an integer --false
put "THIS" = "this" --false -exact value not the same *

* strictCompare 1 would leave caseSensitive set at false so basic string
values can be compared as is, but at strictCompare 2 the caseSensitive
would be set to true so all comparisons of exactness return a logical
result.

Some edge cases:

set the strictCompare to 0
put 0.1 = .1  --true -value is the same
put .1 is a number --true
put 1. is a number --true
put 1.0 is an integer --true
put 0.1 is an integer --false
put .1 is a number --true
put 1. is an integer --true

set the strictCompare to 1 --without a preceding or trailing 0 . is coerced
to a period **
put 0.1 = .1  --false - number vs string
put .1 is a number --false --it's a string
put 1. is a number --false --it's a string
put 1.0 is an integer --true as it's coerced to 1, 1 = 1.0
put 0.1 is an integer --false
put .1 is a number --false --it's a string
put 1. is an integer --false --it's a string

set the strictCompare to 2 --without a preceding or trailing 0 . is coerced
to a period **
put 0.1 = .1  --false - number vs string
put .1 is a number --false --it's a string
put 1. is a number --false --it's a string
put 1.0 is an integer --false, it's a number with a fractional part, 1 <>
1.0
put 0.1 is an integer --false
put .1 is a number --false, it's a string.
put 1. is an integer --false, it's a string.

** The reason in my mind that . should be considered a period in 'strict'
mode (2 or 1) is that in the vast majority of text that might be parsed, if
it's come in (via a spreadsheet or some other means) as a number it will
have preceding or trailing zeros if there is a decimal point and clearly be
a number; otherwise it would be as part of a chunk of text:

1. A 3 item list
2. Now there are 2.
3. The last item.

LC already provides a way for us to easily extract the value of these
numbers out of the chunk of text, but only by strictCompare set to 0 or 1
would it be possible to easily determine that these numbers are in fact
just strings in amongst words as part of lines of strings. There is no "is
a string" function - and I'm not suggesting there should be - but just
because 'is a number' returns false can be used to assume you have a
string, it will also give you false positives.

So in the list above 'word 3 of line 1 is a number' should return false if
strictCompare is set to 2 or 1 because strictly the whole lot is stored as
a string so the 3 in 'A 3 item list' even without a preceding or trailing .
is still a string.