Update classify.rst - clarify that <true> is boolean, not string

[philipmgrant]

In the "list of classification values" table, the examples for boolean-typed values are shown as the single-quoted string 'true'. Change this to the formatted boolean literal true.

[fxdupont]

Not convinced there is something to fix here: values are represented as strings so true is really the string "true". As the grammar is typed there is no possible confusion between the value of the boolean true and the value of the string "true" even of course they are the same.

The grammar has two entries: one returning a boolean, the second a string. There are tokens to bridge between expressions of the two types:

• '==' : string x string -> boolean
• 'ifelse' : boolean x string x string -> string

For the token == the result value is logged as ''true'' i.e. the same as for the token string (litteral string) for "true".

Of course here I assume that all expressions are produced by the parser and not built directly from tokens but this is the case at the exception of a few unit test.

[philipmgrant]

Here's the specific scenario that prompted me to make the PR.

I tried to write a class definition like this:

{
        "name": "foo-class",
        "test": "member('bar-class') == 'false'"
}

because, based on the documentation, I assumed that the member() expression yielded a string 'true' or 'false'.

But that gave an error, and I had to write:

{
        "name": "foo-class",
        "test": "not member('bar-class')"
}

That's a better syntax, I'm not complaining about that! But it seems like there really is a difference between an expression that returns a boolean (as member() actually does) compared to an expression that returns a string (which I thought, based on the documentation, that member() did).

[fxdupont]

BTW in "member('bar-class') == 'false'" what the returned value did you expect? The List of classification expressions table says the Equal (==) returns true or false so it is not ambiguous.