> Bob S wrote:
> There is already a string keyword.
>
True. ‘Stringify()’ or ‘’evaluateAsString()’
It’s easy enough to write a function to force string comparisons for those rare
edge cases like "6. " is equal to "6.” where the engine automatically converts
the strings to numbers.
Yes.
Bob S
> On Sep 6, 2018, at 13:07 , Richmond Mathewson via use-livecode
> wrote:
>
> I wonder is the reason "6" and "6." are treated as the same is because "6."
> is read as "6.0"?
>
> Late to the party, I know . . .
>
> Richmond.
___
There is already a string keyword.
Bob S
> On Sep 6, 2018, at 21:53 , Jim Lambert via use-livecode
> wrote:
>
>
>> RichardG wrote:
>> Any suggestions for a new operator token to specify numeric equivalence?
>
> Or maybe to specify string equivalence.
>
>> Did anyone know that "6. " is
Hi
We had the same "problem" in Foxpro because of the Dbase legacy.
Here is a partial list of comparisosn with the SET EXACT switch
setting
OFF ON OFF or ON
"abc" = "abc" Yes Yes Yes -- 1
"ab" = "abc" No No No -- 2
"abc" = "ab" Yes No No -- 3
"abc" = "ab_"
> RichardG wrote:
> Any suggestions for a new operator token to specify numeric equivalence?
Or maybe to specify string equivalence.
> Did anyone know that "6. " is equal to "6."???
string( "6. “) is not equal to string( "6.”)
where the function string() would tell LC not to try to
Mike Kerner wrote:
I like the is vs = idea.
Me too, but I'm afraid decades of code across the entire xTalk world
form a substantial enough legacy to render the change prohibitive.
Any suggestions for a new operator token to specify numeric equivalence?
--
Richard Gaskin
Fourth World
Bob Sneidar wrote:
> Yes, but it's the kind of thing that can bite a new programmer in the
> butt.
HyperTalk had a reputation for being difficult to learn. ;)
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
"bite a new programmer in the butt" . . . well, as a person who was a
new programmer in 1975 and found
things very difficult to understand at first (FORTRAN IV) I certainly
don't remember having a sore bottom!
I do know, that is numerical calculations empty spaces are exactly that:
empty
I wonder is the reason "6" and "6." are treated as the same is because
"6." is read as "6.0"?
Late to the party, I know . . .
Richmond.
On 6/9/2018 10:34 pm, Jim Lambert via use-livecode wrote:
Did anyone know that "6. " is equal to "6."???
It’s somewhat similar to
value(“h “) is
Yes, but it's the kind of thing that can bite a new programmer in the butt. And
the trouble with your comparison is that length("7. ") IS equal to length("6.
"). So multiple comparisons have to be made. But this is an edge case I admit.
I was only trying to maintain an index number for a
> Did anyone know that "6. " is equal to "6."???
It’s somewhat similar to
value(“h “) is equal to value(“h”),
while
“h “ is not equal to “h”.
I’m not disturbed but appreciative that the engine tries to convert both sides
to numbers when doing a comparison. Just must remember
I like the is vs = idea. I disagree with Paul that this is a price of it
being typeless. No other whitespace character in LC seems to cause this
behavior. It's not really true that it's typeless e.g. a blob (even though
technically a blob is a type). It's just that the typing is implied and
I have come across this before . I think what I encountered was "" = 0
I had to do a workaround, figured it was a a decision based on other engine
factors.
I can see it being ok in 99% of cases.
On Thu, Sep 6, 2018 at 1:25 PM Mike Kerner via use-livecode <
use-livecode@lists.runrev.com>
Ignoring the leading or trailing whitespace is weird and counterintuitive.
If the language was more perfect, I think it would first not ignore the
other characters in the string no matter what they look like, then do the
implicit type coercion and then the comparison, even though there are
On 9/6/2018 11:46 AM, Bob Sneidar via use-livecode wrote:
> Did anyone know that "6. " is equal to "6."???
>
> THAT is disturbing! So now we have to check the length of a string as well to
> make sure there is an exact match???
>
This is the price of having a "type-less" programming language.
By way of rehtoric, and by no means a suggestion of any change in the engine,
it might have been better if "is" did a strict string comparison, while "=" or
"is equal to" attempted a numerical type conversion, and reverted to a string
comparison if either arguement failed.
What *might* be
On 2018-09-06 18:52, Mike Kerner via use-livecode wrote:
Right. If the explanation is clear then it's not an issue (even if it
is a
little weird - "6.abc"="6.xyz" is false but "6." is "6." is
true)
Well the explanation can be fixed :)
Its hard to say whether the language would be better or
Right. If the explanation is clear then it's not an issue (even if it is a
little weird - "6.abc"="6.xyz" is false but "6." is "6." is true)
On Thu, Sep 6, 2018 at 12:43 PM Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:
> On 2018-09-06 18:21, Mark Wieder via
On 2018-09-06 18:21, Mark Wieder via use-livecode wrote:
Yeah. IMO automatic type conversion is one of the failure points of
the xtalk paradigm, but it's always been thus.
To be fair, in the days of HyperCard when everything was strings (and
numbers were decimal strings) the rules worked
On 2018-09-06 18:14, Mike Kerner via use-livecode wrote:
Dictionary:
First, if you look in the operands, it says
*The operands value1 and value2 can be numbers, literal strings of
characters (delimited with double quotes), or any sources of value,
including arrays.*
The example for comparing two
On 09/06/2018 09:06 AM, Mark Waddingham via use-livecode wrote:
P.S. The engine has *always* worked like this - as have xTalks in
general. It's why you never have to put any explicit type conversion
anywhere when you are interchanging anything and things still work as
expected.
Yeah. IMO
so the description seems to imply that the comparison should be as strings
if double-quotes are included around the literals.
On Thu, Sep 6, 2018 at 12:14 PM Mike Kerner
wrote:
> Dictionary:
> First, if you look in the operands, it says
> *The operands value1 and value2 can be numbers, literal
Dictionary:
First, if you look in the operands, it says
*The operands value1 and value2 can be numbers, literal strings of
characters (delimited with double quotes), or any sources of value,
including arrays.*
The example for comparing two strings is
"ABC" = "abc" -- true if and only if
On 2018-09-06 18:02, Mike Kerner via use-livecode wrote:
dictionary says when comparing strings we go char by char, and says
that
quotes around the literal causes it to be evaluated as a string.
Where in the dictionary? That should be revised.
Quotes make no difference - numbers and strings
It seems as long as all characters in the string can be numerical values, they
are treated as such. Space is treated as whitespace or empty. My guess for «6»
+ «6» to return 12 was right.
Tore Nilsen
---
This mail contains no viruses or bacteria as it is electronically produced and
dictionary says when comparing strings we go char by char, and says that
quotes around the literal causes it to be evaluated as a string.
On Thu, Sep 6, 2018 at 11:57 AM Mike Kerner
wrote:
> If I put anything else in place of the dot, I get a fail, but with the
> dot, i get true
>
> On Thu, Sep
I think this is because the dot is also the decimal sign. Therefore it
interprets the strings as numerical values. And = and is are synonyms.
I guess if you write something like put «6» + «6» you will get 12 as the result.
Best regards
Tore Nilsen
---
This mail contains no viruses or
If I put anything else in place of the dot, I get a fail, but with the dot,
i get true
On Thu, Sep 6, 2018 at 11:55 AM Tore Nilsen via use-livecode <
use-livecode@lists.runrev.com> wrote:
> It seems to only compare the integer part of the statements. If you
> substitute the integer with a
wow. that's not cool. I just tried "is" and yep. is.
On Thu, Sep 6, 2018 at 11:47 AM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Did anyone know that "6. " is equal to "6."???
>
> THAT is disturbing! So now we have to check the length of a string as well
> to make
It seems to only compare the integer part of the statements. If you substitute
the integer with a letter, then it reports false. But still strange as the
quotation marks should indicates that this is a string.
Best regards
Tore Nilsen
---
This mail contains no viruses or bacteria as it is
30 matches
Mail list logo
