Rui Nuno Capela wrote:
>However I personally find this new quoting requirement rather strange.
>Forgive my lex/yacc ignorance, but is it really unavoidable? Is it really
>impossible having a syntax where a token is distinguishable from a
>arbitrary literal value? Is it a lex/yacc fundamental limitation or what?
>I'd rather have quotes optional, and only required where strictly
>necessary, like e.g. in comma-separated list items.
>
I'm not sure the quoting was actually /unavoidable/. I suggested a couple of
ways the parser might have been fixed without introducing quotes but they
were difficult and/or inefficient and i'm not 100% sure they would have
worked.
The argument for the introduction of quotes is:
Its easier and more efficient to tokenise the protocol and then parse the
token-stream than it is to parse the protocol directly one character at
a time. Thats why lex and yacc exist as two separate tools.
To tokenise the protocol its parts must be /lexically/ (as opposed to
syntactically) distinguishable from each other.
The protocol carries arbitrary, user-entered strings, eg channel names,
which can only be lexically distinguished if they are delimited in some
way.
Hence the quotes.
Note that it is ONLY the values of string parameters which have the
quotes now. Setting a channel name looks like this:
SET AUDIO_OUTPUT_CHANNEL PARAMETER 0 0 Name="Monitor Left"
but setting a numerical parameter is still:
SET AUDIO_OUTPUT_CHANNEL PARAMETER 0 0 Whatever=2.27
Note also: The lexical analyser needs the quotes to see the strings,
but it "eats" the quotes as soon as it has seen them. It gives the
parser a string without quotes, and thats what the parser gives the
server.
Its the packaging that has been changed, not the contents.
Simon Jenkins
(Bristol, UK)
|
