UCI nullmove

[rjgibert]

Code: Select all

* all command strings the engine receives will end with '\n',
  also all commands the GUI receives should end with '\n'

Unfortunately this does not solve anything. Because it does NOT say that a command cannot contain internal linefeeds. It only says that each command ends with '\n'. That is NOT the same as that every '\n' ends a command.

Like has already been pointed out by several others, the UCI specs simply suck in the extreme.

While in an "english sense," there may be some ambiguity, in a programming context, there is no ambiguity with this at all. It's understood that any internal '\n' is excluded. '\n' is clearly intended as a command terminator.

Properly understanding what a command terminator is, removes the possibility of your alternate interpretation. A command terminator indicates the end of command and does so by its first occurance. Obviously, it's possible to depart from this convention, but this would be explicitly indicated. No mind reading required.

The UCI specs might suck, but this is not an example.

[hgm]

There must be something wrong with my eyes then. I don't see the term 'command terminator' anywhere. Could you underline it in the quote?

All commands from xboard to the engine end with a newline (\n), even where that is not explicitly stated. All your output to xboard must be in complete lines; any form of prompt or partial line will cause problems.

Can you also explain how your proper understanding of the not-mentioned 'command teminator' makes the meaning of the above quote from WB protocol specs so different?

[Rein Halbersma]

From "Alice Through the Looking Glass" :

Code: Select all

`When _I_ use a word,' Humpty Dumpty said in rather a scornful tone, `it means just what I choose it to mean -- neither more nor less.'
 
  `The question is,' said Alice, `whether you CAN make words mean so many different things.'
 
  `The question is,' said Humpty Dumpty, `which is to be master -- that's all.'

[rjgibert]

There must be something wrong with my eyes then. I don't see the term 'command terminator' anywhere. Could you underline it in the quote?

All commands from xboard to the engine end with a newline (\n), even where that is not explicitly stated. All your output to xboard must be in complete lines; any form of prompt or partial line will cause problems.

Can you also explain how your proper understanding of the not-mentioned 'command teminator' makes the meaning of the above quote from WB protocol specs so different?

Quoting from what I wrote: "...intended as a command terminator..."

[hgm]

So that was just a private guess?

But guessing is unfortunately not what this thread is about. There request wast for an opinion-free interpretation, staying away from the 'deadly broken "because I don't see what else could be" way of reasoning'...

Of course it is very easy to dream up things like "it would work great if \n was defined to be a command terminator", or "it would work great if bestmove 0000 would mean resign", and a dozen others. But there are some that do not want to hear such fanciful interpretations, and want to go "by the book" of what is exactly written.

Well, unfortunately it is NOT written that \n is a command terminator, and how to handle the case when it is received at a time where a syntactically incorrect or incomplete command is received. Because even with command terminator that would be ambiguous: incorrect commands could be completely ignored, or they could be partially executed. So assuming \n is a command terminator only increases the ambiguity for how bestmove immediately followed by \n should be handled. While assuming it is just a token like any other does in fact unambiguously solve every conceivable situation through the rule that invalid tokens should be ignored (albeit in an often idiotic way).

[rjgibert]

So that was just a private guess?

But guessing is unfortunately not what this thread is about. There request wast for an opinion-free interpretation, staying away from the 'deadly broken "because I don't see what else could be" way of reasoning'...

Of course it is very easy to dream up things like "it would work great if \n was defined to be a command terminator", or "it would work great if bestmove 0000 would mean resign", and a dozen others. But there are some that do not want to hear such fanciful interpretations, and want to go "by the book" of what is exactly written.

Well, unfortunately it is NOT written that \n is a command terminator, and how to handle the case when it is received at a time where a syntactically incorrect or incomplete command is received. Because even with command terminator that would be ambiguous: incorrect commands could be completely ignored, or they could be partially executed. So assuming \n is a command terminator only increases the ambiguity for how bestmove immediately followed by \n should be handled. While assuming it is just a token like any other does in fact unambiguously solve every conceivable situation through the rule that invalid tokens should be ignored (albeit in an often idiotic way).

I was responding to what you quoted:

Code: Select all

* all command strings the engine receives will end with '\n',
  also all commands the GUI receives should end with '\n'

I don't know why you included the asterisk there. Presumably, you are clipping a part of comment and this is ignorable. Now let's focus on

all command strings the engine receives will end with '\n'

Key words to note: "all", "command" and "end"

Now note the word "command" in that line. This line is about commands and is indicating that /n ends—meaning terminates—all commands. Hence, /n is a command terminator as opposed to a command separator.

If the role of /n were intended as a separator the word "all" would not be present or the word "except" would appear preceding some type of qualification. Since "all" is present without qualification, the role of /n is as a terminator. If the role of /n were as a separator, it would not be required for the last command. The use of the word "all" in the above line precludes this interpretation.

The above is how I parsed what you quoted. I assumed you did not omit anything relevant in the context from which it came from.