At 5:16 PM -0500 4/10/00, Gilles Detillieux wrote:
>I'm still not satisfied with the config parser. Unless I'm misreading
>the grammar, it looks like there are a lot of potential problems lurking
>in it. It seems that for the value of any parameter, it will only allow
>a string, a number or a list, where a list is defined as:
I would agree with this sentiment in general. However, please see my
notes below.
>list: T_STRING T_STRING
> | list T_STRING
> | list T_NUMBER
>
>But in reality, it should be possible to set an attribute's value to
>just about anything. The grammar defines these as valid tokens:
>
>%token NUM T_DELIMITER T_NEWLINE T_RIGHT_BR T_LEFT_BR T_SLASH
>%token <str> T_STRING T_KEYWORD T_NUMBER
Right, but it doesn't make it clear what they are. It's pretty easy
to work out that T_DELIMITER is ':' T_NEWLINE, T_RIGHT_BR, T_LEFT_BR,
and T_SLASH are also IMHO self-explanatory. This leaves NUM, <str>
(I'm guessing this is for the blocks), T_STRING, T_KEYWORD and
T_NUMBER.
As you say, it seems that T_KEYWORD are essentially strings on the
left-hand side of delimeters. If so, that makes them
*context-dependent* and the interpretation depends on where it is.
I still don't know what NUM is.
>so that leaves a lot of tokens that it will not allow within
>a list. Aren't keywords allowed as attribute values? After all,
Nope. Since a keyword is only a keyword on the left side, it's a
string here. It seems an odd distinction, but that's what I see.
>build_select_lists allows (even requires) that some of the list items
>be attribute names, which the grammar seems to treat as T_KEYWORD.
Well, but the *parser* itself doesn't validate. Otherwise, it would
have to have a list of T_KEYWORDS. We talked about this a few weeks
ago, but this isn't a validating parser. Since this code has makes a
contextual difference between a T_STRING and a T_KEYWORD, in a list,
it's just a T_STRING. That it happens to be the same string as a
keyword is meaningless *to the parser.* (It may have meaning to the
code, of course.)
>What about a list that begins with a number? The list syntax seems to
>require lists to begin with at least two strings.
OK, here I'd agree that makes sense. However, I'm not even sure my
code for adding a number onto a list is correct. It seems to work,
but I also just copied the code from the list T_STRING case. If you
feel I should do the same for T_NUMBER T_NUMBER, I'll do so, but it
"felt wrong" to me.
-Geoff
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
