Re: [classad-users] Bug related to keywords

[Marvin Solomon <solomon@xxxxxxxxxxx>]

Alain Roy wrote:
>
>> The issue is
>> If we have a classad:
>> [error = 1]
>> In spite of the attribute name being a keyword the parsing succeeds
>> because the name is quoted.
>> However when the ClassAd gets Unparsed, it spits it out as:
>> [error = 1]
>> Now if we try to parse this again, the parser bails out.
>
>
> I'm betting that it's still an issue--thanks for pointing it out!
>
>> Ive fixed this issue in both the Java & C++ libraries by getting the
>> unparser to spit it out with single-quotes.
>
>
> Can you send me patches?
>
>> However, Im wondering, if thats the best solution.
>> Would you rather have the parser succeed if it encountered [error =
>> 1], because the keyword is actually an attribute-name & hence the
>> parser shouldnt mind it.
>
>
> It's a good question, and I'm not sure what the answer is--it's not
> clear to me from the reference manual. Marv--do you have some input on
> this?
>

Swaroop has indeed uncovered a design flaw in the language spec.  I would
characterize it by saying that the "canonical unparsing" is not invertable --
it does not create a legal expression in the "native" syntax.  The words
"error", "false", etc. are actually "reserved words", not keywords.  In
Section 3.1, Abstract Syntax:

    "The following words are reserved, meaning that they may not be used as
    attribute names.

        error false is isnt parent true undefined

    Recognition of reserved words is independent of case. For example, false,
    FALSE, and False are all reserved words."

Also, in Section 3.3.1, Tokens,

    "The name reserved_word denotes any of the strings

        error false is isnt parent true undefined

    in any combination of upper or lower case letters."

In the jargon of language design, a keyword has a predefined meaning in the
language, but can be overriden by the user.  An example is String in Java or
stdout in C.  By contrast a reserved word, as the term implies, is reserved; it
may not be used for any other purpose.  Examples in Java or C++ include "if"
and "class".  I don't think it would work to relax restrictions on the 7
reserved words in the classad language.  For example, what's the value of x in

    [ false = 1; x = false; ],

or still worse

    [ false = true; x = false; ]?

I prefer Swaroop's suggestion to modify the unparsing rules.  The change to the
refman would be to change Section 3.3.1 to read
    If the sequence conforms to the syntax of unquoted_name and is not a
                                                            ++++++++++++
    reserved word, the attribute name may be represented using either syntax.
    +++++++++++++
and 3.3.3 to read
    The canonical unparsing of an attribute name is simply the name itself if
    it conforms to the syntax of unquoted_name in Table 4 and is not a reserved
                                                          +++++++++++++++++++++
    word.
    ++++

I'll check in a fix to the Java implementation.