Re: test palette

[Ethan M. <merritt@u.washington.edu>]

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