Forcing string comparisons, or When is "0" not 0?
dunbarx at aol.com
dunbarx at aol.com
Thu Oct 15 13:17:44 EDT 2015
See a feature request I made in the forums. Whichever is the best/easiest/most robust is up for grabs.
Craig Newman
-----Original Message-----
From: Mark Waddingham <mark at livecode.com>
To: How to use LiveCode <use-livecode at lists.runrev.com>
Sent: Thu, Oct 15, 2015 1:08 pm
Subject: Re: Forcing string comparisons, or When is "0" not 0?
On 2015-10-14 22:19, Devin Asay wrote:
> Shouldn’t there be a way to force a
string comparison? I know LC tries
> to be all helpful about casting numerals as
numbers, but what if I
> want to know if it’s the exact string?
I think this is
one of those things which has come up periodically over
the years...
We added
'is really a' operators in LC8 to help with writing code which
needs to
preserve values exactly (the main use-case is lcVCS) - so we
have been
considering an 'is really' operator.
(It occurs to me this morning that perhaps
these should be 'x really is
a string', or 'x really is y' as opposed to 'x is
really a string', or
'x is really y' - I'm not sure which is 'more correct' in
English)
The 'is really a' operators check the internal (dynamic type) of the
value, by-passing any type-coercion:
'x is really a string' -> returns true
if the current value of x is
(internally) a string
'x is a string' ->
returns true if x can be converted to a string
So, the 'is really' operator
would do much the same thing:
'x is really y' -> returns true if the internal
types of x and y are
the same, and they are the same value
'x is y' -> if x
and y can be converted to numbers then compare as
numbers else compare as
strings
The problem with 'is really' is that to truly understand what it is
doing, you have to explain about whilst LiveCode is a 'typeless'
language
(assuming you ignore the existence of arrays ;)), the engine
still has a notion
of distinct types internally (it needs to store the
values in memory in some
chosen representation after all) and the
internal type of a value depends on
how the value was last produced:
put "0" + 0 into tVar1 -- tVar is really a
number
put "0" & 0 into tVar2 -- tVar is really a string
put tVar1 is
really tVar2 -- false
The other option (which has the potential advantage of
not exposing the
7.0+ under-the-hood dynamically typed nature) is to have an
explicit
'compare as string' operator (for purposes of exposition let's call it
is_string) for now. The action of such an operator would be to convert
both
sides to strings (if possible) and then compare:
put "0" is_string "0." --
false
put 0+0 is_string char 1 of "0." -- true
This is subtly different
from is really:
put 0 + 1 is really "1" -- false
put 0 + 1 is_string
"1" -- true
Indeed, if we imagined that we had 'as <type>' operators then:
x is_string y <=> (x as string) is really (y as string)
So, anyway, a couple of
potential solutions (I think 'is really' is a
useful compliment to the 'is
really a' operators, the question is
whether there is a nice syntax for
is_string and whether it is a useful
thing to have).
Warmest
Regards,
Mark.
> I guess I could do this dance:
>
> if char 1 of fld
“display” is “0” and char 2 of fld “display” is NOT
> “0” then…
>
> It’s seems
to complicated for such a simple thing, especially for
> explaining to novice
programmers. Maybe I’m missing something obvious.
>
> Devin
>
>
> Devin
Asay
> Office of Digital Humanities
> Brigham Young University
>
>
_______________________________________________
> use-livecode mailing list
>
use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe
and manage your
> subscription preferences:
>
http://lists.runrev.com/mailman/listinfo/use-livecode
--
Mark Waddingham ~
mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create
apps
_______________________________________________
use-livecode mailing
list
use-livecode at lists.runrev.com
Please visit this url to subscribe,
unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
More information about the use-livecode
mailing list