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