Project

Profile

Help

HostedRedmine.com has moved to the Planio platform. All logins and passwords remained the same. All users will be able to login and use Redmine just as before. Read more...

Bug #157507

open

clarifications needed

Added by Clark Barrett almost 11 years ago. Updated about 10 years ago.

Status:
New
Priority:
Low
Start date:
2013-03-09
Due date:
% Done:

0%

Estimated time:

Description

Morgan Deters <>
7/26/12

to Clark
Hi Clark,

You asked today if I could point you to a point of confusion in the
standard I found recently.

It's confusing as to what the set of responses to certain commands can
be. The standard defines a "general" response:

&lt;gen_response&gt; ::= unsupported | success | ( error &lt;string&gt; )

But some commands have other responses. Page 37 states that "In place
of success, one of the elements of <gen_response>, some commands
provide a more specific response." This seems to imply that it's ok
to give a gen_response response (except for success) to any
command, including those with more specific responses, but this is far
from clear. In fact, the first time I read it, I thought it meant
that <gen_response> was completely superseded by the specific command
responses---which means "unsupported" and "error" responses cannot be
issued for these more-specific commands! This interpretation is
strengthened by what follows on page 38: "Solvers respond to commands
with the responses defined above. General responses <gen_response> are
used unless more specific responses are specified, for example for
get-info (<get_info_response>) or get-value (<get_value_response>)."
(Emphasis mine.)

But clearly, "unsupported" and "(error..)" should be permitted for
these more specific commands. Perhaps to fix this, an <error> should
be defined by the standard which is "(error...) | unsupported", and
then a gen_command should be "<error> | success", and then all the
specific command responses should have "| <error>" tacked onto the
end? This would make the point explicitly in the concrete (and also
abstract) syntax.

Another minor point is that it's unclear how to respond to something
not a command. Let's say a user commits a typo and writes (get-nfo
:foo). Obviously something like (error "get-nfo is not a command")
should be issued. But, since "get-nfo" is not a command, "error" is
not a valid response.

Actions #1

Updated by Clark Barrett about 10 years ago

  • Assignee set to Cesare Tinelli

Also available in: Atom PDF