[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

escapes in quoted strings?



Looking over the spec, one omission/confusion that immediately springs
to mind is the lack of mention of of how one escapes characters within
quoted strings (i.e., for values).  I'm not sure whether the intent is
that values should be any possible 7-bit ASCII string or merely the
7-bit-printable/readable ASCII string (i.e., ASCII 32-126 + TAB (maybe))
that MOO supports, and perhaps you want to stay vague about that (*).
But in any case it should be clear about how one sends basic printable
things like quotes (") and stars (*).

I notice that you *do* have 
  <string-char> := <simple-char> | <space> | '\"' | ':'
in your grammar.  At the very least, this should be
  <string-char> := <simple-char> | <space> | '\"' | '\\' | ':'

But then I noticed that one is evidently *not* allowed to send stars (*)
in quoted strings which seems extremely odd, whether this be an
oversight or someone wanted a way to quickly tell whether multiline
values were expected to follow and not have to fully parse the message.


I figure there are two sensible ways to do things:

(1) NO ESCAPES.  
  <string-char> := <simple-char> | <space>

Quoted strings may not contain quote ("), colon (:) or star (*); if you
want a value to contain one of these characters you must send it as a
multiline.  Period.  

This has the advantage of not having to parse received quoted strings
for escape characters.  If you go this route, you should require for any
given keyword that multiline values be accepted whenever the
corresponding non-multiline value is accepted.

(2) DEFINE AN ESCAPE CHARACTER AND MAKE IT POSSIBLE TO REPRESENT GENERAL
STRINGS
The key point is that if you're going to this trouble, your escape
mechanism should allow for the sending of general strings, including at
the very least, the quote (\") and the escape character (\\) itself, and
also colon and star.  

If an MCP agent (client or server) cannot assume that any given
(single-line) string indeed has a quoted version, and thus has to allow
for the possibility that any of the values it is sending may need to go
out as a multiline, you basically lose the benefit of having escape
characters.