Text string bug

[LCMark]

I should point out that the behavior observed here is a semantic of the comparison operators - it has nothing to do with how literals are interpreted.

Just like many other scripting languages (e.g. JavaScript), comparison operators try numeric comparison first and then string.

EDIT: JavaScript is not that good an example (it only does numeric if the types of the two sides are mixed); PHP is a better one!

[dunbarx]

Mark.

(it only does numeric if the types of the two sides are mixed);

How does it do numeric with mixed strings?

Craig

[stam]

Is the issue not with the presence of quotes rather than a discussion of types?

I think most would consider anything wrapped in quotes to be a string, or to be treated like a string. Prefixing it with a text character is a kludge but amounts to the same semantic effort...

[LCMark]

@stam: I don't see the distinction - you are wanting quotes to indicate type.

As my previous example was meant to illustrate, I don't see how you can have "100" act differently from item 2 of "0,100,200" - one is a string literal, the other is a substring of a string literal.

You argue that as there are no quotes around 100 in item 2 of "0,100,200" so the difference all makes sense - but then by the same logic, shoudn't "100" be the string QUOTE 100 QUOTE (otherwise there's a huge inconsistency there!).

At the end of the day xTalks do not generally make a distinction between numbers and numeric strings (i.e. strings which are valid decimal numbers in some notation or another). The usage of quotes in the syntax is to ensure you can express things which otherwise would be understood as syntax (i.e. things with spaces in it, or things which are keywords).

The upside of this is that in virtually all cases you don't have to explicitly indicate whether something is a string or a number to get a desired effect - however this thread is entirely down to the one of the cases where you *do* have to - because the comparison operators are designed to not make a distinction, and thus cause a problem when you don't actually want to do numeric comparison. (So the only upshot of this thread really is that LC perhaps needs a set 'please compare these two things as strings, and only strings, operators').

[FourthWorld]

(So the only upshot of this thread really is that LC perhaps needs a set 'please compare these two things as strings, and only strings, operators')

Would optional type declarations be a feasible candidate for solution to this need?

[stam]

You argue that as there are no quotes around 100 in item 2 of "0,100,200" so the difference all makes sense - but then by the same logic, shoudn't "100" be the string QUOTE 100 QUOTE (otherwise there's a huge inconsistency there!).

@Mark: In truth i've not had an issue like this, so i'm guessing this is not a common problem - but playing devil's advocate:

Semantically i would argue that "100,200,300" can be viewed as both a string but also as a container, analogous to a numerically indexed array in other languages.

By using 'item of' you are implicitly declaring/treating this as a container/1-based array and not a string - as such there is no inconsistency.

Still not sure i see what the problem with using quotes to denote a string is - ie a scenario in which this would have a negative impact?

Stam

[LCMark]

Semantically i would argue that "100,200,300" can be viewed as both a string but also as a container, analogous to a numerically indexed array in other languages.

So "100,200,300" can be viewed as a string 'and something else' - but "100" can only be viewed as a string? That seems a little inconsistent

By using 'item of' you are implicitly declaring/treating this as a container/1-based array and not a string - as such there is no inconsistency.

By using 'is' you are indicating you want to see if the two values on either side are the same from any point of view - whether that be as strings or as numbers.

My point here is that LC generally defines what happens by the operations you perform, and not what the representation of the things being operated on are.

Code: Select all

Still not sure i see what the problem with using quotes to denote a string is - ie a scenario in which this would have a negative impact?

So quotes do denote a string - but LC's operations (such as 'is') do not care that something may be a string as they are defined to operate regardless of representation (obviously in some cases you get an error `"a" + 1`, is invalid, for example).

I do actually think the comparison operators are the real especially 'irksome' case here - after all arithmetic operations need numbers, so the not caring has no negative side-effects.

However, the reason they do what they do is because if they did not then you would get discontinuity in manipulation of strings which give rise to numeric strings.

Consider:

Code: Select all

put "100" is 100
put ("1" & "00") is 100
put item 2 of "1,2,3" is 2
put "100" into tVar; put tVar is 100

With current semantics, these all return true. If quotes affected comparison in the way you suggest then (1) would be false, (3) would be true - and who knows what you might think (2) and (4) should be .

[dunbarx]

I think we can all live with this and agree about the tiny "inconsistencies" that may only mean anything with comparisons.

i want to ask again, though, about JavaScript:

Mark wrote:

it only does numeric if the types of the two sides are mixed

How does it do numeric with mixed strings?

Craig

[LCMark]

Would optional type declarations be a feasible candidate for solution to this need?

It potentially could, but I think that would be a bit of a sledgehammer in this case

One quite xTalky way of resolving this issue is through string-only comparison operators - as its in keeping with the 'types don't matter, but what you ask to be done does' philosophy which seems to have implicitly underlined the evolution of this type of language.

To resolve the issue with the 'swiss army knife' is, for example, simply requires being able to state what 'type' you want to compare things as. e.g.

Code: Select all

put "100" is string 100 -- true
put 0 is string "0E0" -- false
put "a" is number "a" -- false (its an open question whether this should actually throw an error or not!)
put "100" is number "1.0e2" -- true

The problem comes with finding similarly simple syntax for relational operators - <, >, <=, >= - although I guess the following aren't too unpleasant:

Code: Select all

put "20" < string "3" -- true
put "20" < number 3 -- false

Another potential option is to add a context-local variable to control it - bearing in mind the only really problem here is with wanting to force a string comparison you could have something like:

Code: Select all

set the compareNumeric to false
put "000" is "0E0" -- false
set the compareNumeric to true
put "000" is "0E0" -- true

In someways, perhaps the latter is a little more palatable for relational tests - albeit slightly more verbose - it also has the advantage of not using keywords in contexts which might get confused with the same ones used for any 'optional typing' facilities added at a later date...

[LCMark]

How does it do numeric with mixed strings?

Heh - I didn't write that very well - JavaScript attempts to compare numerically if one side is a number. If both sides are strings then it compares as strings.

So, in that sense, JS does not have this string comparison issue ("000" == "0e0" is false in JS) *however* the balance to that is that if you want something you've cut out of a string to behave numerically you pretty much always have to explicitly convert it.

[dunbarx]

@Mark.

JavaScript attempts to compare numerically if one side is a number. If both sides are strings then it compares as strings.

OK, thanks.

This is so much more fun for me than all that stuff about databases.

Craig

[SparkOut]

I had my brain wrenched in the thread that I linked to, and could not see how anything quoted should be interpreted as anything but a string literal.
Following that thread and the linked quality report and subsequently, I have somehow come to understand that it isn't so black and white.
I don't know what the "best" answer is, but I suspect somehow that letting go of the string literal only interpretation is involved.
I am not sure I like it, and I am certainly not used to it, but I can reconcile it a bit with allusion to boolean comparison as in "some text" resolving to true and 0 resolving to false.
I am a bit more sold on having

Code: Select all

put "100101" into tString
if char 1 to 3 of tString < char 4 to 6 of tString then ...  

resolving properly

[stam]

Thanks for the explanations @LCMark - while i haven't so far been troubled by this, i, like others here, assumed quotes would cast the value as a string but good to know that assumption is completely wrong

[jacque]

I just learned a whole lot.

[mwieder]

Would optional type declarations be a feasible candidate for solution to this need?

Ha. Back when we were open-source I actually had this partially coded in the engine.
But that was then.