LC inconsistency in valuation ?

[trevix]

If you put in the message window of LC 7.1.2 (or you make a valuation of a field) this:

Code: Select all

put "" = empty 

return true: correct

Code: Select all

put "Yes" = empty

return false: correct

Code: Select all

put "No" = empty 

return false: correct

Code: Select all

put Yes = empty 

return false: mmmh...Yes should be evaluated as an empty variable, so should be true

Code: Select all

put No = empty 

return ERROR Script compile error:Expression: double binary operator

Can someone explain me this, since "No" shouldn't be a reserved word ?
Thanks

[trevix]

Also

Code: Select all

put "si" = si 

return true (but shouldn't be false ?)

Code: Select all

put "no" = no

return ERROR Script compile error:Expression: missing factor

[LCMark]

@trevix: What you are seeing here is all as expected. Unless you have 'variable checking' turned on, any unquoted single word string (such as yes) will be treated as an 'unquoted literal'. This means it is treated the same as the string (in the example case - "yes") until you actually put something into it (thus causing it to be treated as a variable). So:

Code: Select all

  put yes = empty -- will give false as at this point the token yes is treated the same as "yes"
  put empty into yes
  put yes = empty -- will give true

The no example actually surprised me a bit - it turns out "no" is a synonym for "not". So you can write:

Code: Select all

  if no (tVar is "foo") then

to mean the same as:

Code: Select all

  if not (tVar is "foo") then

[trevix]

OK, thanks
As for the "no" example, in my stack I have an option btn with "yes" and "no".
The choice goes to replace a word in a field that gets valuated. And it does not work with the "no".

Of course i can find other way to fix this but still, to me, it does not make sense to consider "not" and "no" as synonyms.
Will have to manage quotes here and there, without seeing what is the real advantage of using this synonymy.

In the dictionary there is no reference to the fact that "no" is boolean as is "not", except for this example where they are both used without mentioning the fact:

there is no group "Cranky"
put (there is not a folder "Temp") into safeToCreate

So: "No" is boolean. "Yes" is not
Bah...

[LCMark]

@trevix: It would be wise to find another way to do what you are doing. In the general case, a mechanism which uses value() on an unquoted literal where the literal could be part of user input (or come from somewhere which is not compiled script) is not a good idea. The reason is that any keyword which can be used in an expression cannot be used as an unquoted literal, and as LiveCode's syntax is english-like there are a lot of english words which are reserved in this way - also the set of these reserved words increases over time. This is why we generally advise using some sort of naming for variables and such which aren't pure english words - for example by using 'the' as a prefix (which is a common formalism from HyperCard), or the single letter prefixes to help denote what kind of variable it is (e.g. p for parameter, t for local etc.).

If you want to see what the current reserved words are then the full list is essentially the 'factor_table' which you can see here - https://github.com/livecode/livecode/bl ... xtable.cpp - the factor table starts around line 514.