UCI engine authors: Please add support for 'searchmoves'

[Gian-Carlo Pascutto]

UCI is not stateless within lines.
Only after receiving a full line with a complete command it gets back into the same state. What is on the first half of the line might effect the result on what is on the second half very much.

How the parsing of a command works has nothing to do with the protocol being stateless or not.

You can extend your argument and say that no protocol is stateless inside its commands.

So what?

[Michel]

The "result" in terms of the protocol is what the engine does as a result of receiving the commands. Not the move and score.

No I really meant the move and score. The move and score returned may depend on the state of the hash table and hence on the state of the engine.

So the state of the engine influences the result of commands.

[jesper_nielsen]

The "result" in terms of the protocol is what the engine does as a result of receiving the commands. Not the move and score.

No I really meant the move and score. The move and score returned may depend on the state of the hash table and hence on the state of the engine.

So the state of the engine influences the result of commands.

A random mover, that just picks a random legal move and returns as "bestmove" is still a completely valid implementation of the UCI protocol.

How the request is handled has nothing to do with being stateless or not.

Kind regards,
Jesper

P.S. Sorry about the confusion stemming from my editings of my previous posts.

[hgm]

So what?

Well, I would tend to say that statelessness loses much of its attraction when it goes at the expense of an enormous number of unweildly long "commands", that in fact form a protocol on their own and define many micro states. Assigning startpos + move list the status of a single command is a bit doubtfull even from a mathematical point of view. By allowing infinitely many different "commands", the grammar describing protocol sentences might fall in a different class. The only way to parse UCI by a finite state machine is to introduce micro-states.

[Gian-Carlo Pascutto]

So what?

Well, I would tend to say that statelessness loses much of its attraction when it goes at the expense of an enormous number of unweildly long "commands", that in fact form a protocol on their own and define many micro states.

I would think that the statelessness benefits mainly the GUI, which doesn't have to care what state the engine is on, or how to get it from one to another.

I also found UCI a bit of a simplication over handling the original xboard protocol, with edit mode, force mode, and "exit" having different meanings depending on the mode you're in, etc.

[Michel]

How the request is handled has nothing to do with being stateless or not.

Yes. But I was replying to Gian-Carlo Pascutto who said that in a stateless protocol the result of commands should not depend on prior communication (leaving aside the "imperfections" setoption and the position/go split). I was pointing out that in general they do.

[Michel]

EDIT (of previous post)

Ok I misread Gian-Carlo Pascutto's post. He does not consider move and score to be part of the "result" of a command. Only the syntactic form of the reply is relevant.

But this syntactic form would be independent of most (all?) setoption commands. So these commands would then not constitute a deviation of statelessness, contrary to what was asserted...

[Gian-Carlo Pascutto]

How the request is handled has nothing to do with being stateless or not.

Yes. But I was replying to Gian-Carlo Pascutto who said that in a stateless protocol the result of commands should not depend on prior communication (leaving aside the "imperfections" setoption and the position/go split). I was pointing out that in general they do.

You're confusing the protocol with the engine. The result from the protocol commands (the engine starts searching on a given position) should be the same. The result from the engine (bestmove and score) could be anything, and certainly isn't defined by the communication protocol.

[hgm]

The command type with which the engine responds is specified by the protocol. (E.g. bestmove ...) Not the contents of the message.

[Gian-Carlo Pascutto]

Only the syntactic form of the reply is relevant.

I never said that.

I said:

The "result" in terms of the protocol is what the engine does as a result of receiving the commands

and it's clear that this includes respecting the setoption commands, but provides no guarantee for reproducible output or for any specific implementation of finding the best move (such as return movelist[random() % num_moves])

Consider an SMP engine that gives different output each time it is run. Are you claiming it's impossible to make a stateless communication protocol for it, because the engine output differs? That doesn't make any sense.