From: Ethan M. <merritt@u.washington.edu> - 2005-07-27 22:19:47
|
On Wednesday 27 July 2005 02:48 pm, Hans-Bernhard Broeker wrote: > Ethan Merritt wrote: > > On Wednesday 27 July 2005 02:05 am, Petr Mikulik wrote: > > > >>>Several disambiguating keywords have been added already (e.g. "font", > >>>"offset", "at") for exactly this reason. Do you know of any other cases > >>>that are violators, like ... notitle "title"? > >> > >>set label {<tag>} {"<label text>"} > > > > That is unambiguous, since <tag> cannot be a string, and "<label text>" > > cannot be a number. > > It's still at least somewhat ambiguous, because <tag> can be a variable, > which could be either the string or a number. How is that ambiguous? If it evaluates to a number, then it is in fact the label tag (id #). If it evaluates to a string, then it is the label text. The parsing code handles both cases correctly. This was a pain to get right, but it does work. > >>set title {"<title-text>"} > >>set xlabel {"<label>"} > > > What is ambiguous in these commands? > > Well, does > > set title f > > change the title text, the x offset, or the font? We are never looking for a variable or an expression after "set", so "title" is unambiguously a keyword. The version 4.1 syntax wants an explicit keyword "font" before a font string, and an explicit keyword "offset" before an offset. That is what I meant when I said that addition of these keywords has disambiguated the syntax. Old scripts did not use these keywords, but then again old scripts did not use string variables. So backwards compatibility is maintained by accepting commands without these new keywords. But if you want to use string variables, then for correctness you must also use the keywords. You might quibble that `set title "arial"` is somehow recognizable as intending to change the font rather than the title string. But neither the old nor the new code treats this as anything other than the title string. Similarly, `set title "foo" "arial"` is interpreted by both the old (pre 4.1) and the new code as setting both the title string and the font, though 4.1 issues a warning that you should have used a "font" keyword. I think we are in pretty good shape. The guiding rule is to check for all legal keywords first, and only then consider the possibility that it may be a case of deprecated syntax where the keyword is omitted. If the input script predates the introduction of string variables, this works correctly because there will never be a string variable that might be confused with a keyword. If it is a newer script that does use string variables, well then it's a case of operator error if they fail to use the new syntax. But there may be a few commands like the one that started this discussion, where I forgot to add parsing code for the new keywords. Those are the cases I'm asking about. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |