Description From Bob Marinier 2007-10-28 13:28:47 (-) [reply]
When calling RHS functions, generally you would use either "cmd" (for
calling
Soar commands) or exec (for calling custom RHS functions). "cmd"
automatically
puts spaces between the arguments, but exec does not (because people might
want
to concatenate the args).
Dave Ray makes two points about exec: concatenating arguments is definitely
the
less common case, and there is already a concat RHS function that does this
explicitly. I didn't even know there was a concat function (it's not
documented; looking at the code, it appears to have been added by gSKI).
Changing exec now would be bad for compatibility reasons, so Dave and I
agree
that the best option is to introduce a new exec-like function that
automatically puts the spaces between the args (this should result in
cleaner
Soar code, too). Dave suggests that, "in the great Unix tradition", this
function be called execv.
------- Comment #1 From Dave Ray 2007-10-28 14:00:27 (-) [reply] -------
That's funny. I didn't even know that concat was a gSKI thing. In any case,
it's definitely useful.
I was partly joking by suggesting execv, but I can't really think of
anything
better that's still compact enough to not be annoying to type.
Also, I don't think that just putting spaces between the arguments will be
sufficient for the general case. If any of the arguments have spaces in
them,
you've got problems. I'd suggest one of two approaches:
* Expand the RHS function interface to allow for multiple arguments rather
than
the single pArgument we have now. They could come in as a vector of
strings.
This is what the original gSKI RHS function API did.
* If the first approach requires too much fussing with the API, define a
standard way to format the arguments, with escapes as necessary and provide
an
API function that knows how to parse them. Something like:
pArgument = "Argument with spaces", 33, "Argument with \"quotes\""
And then an API function something like this:
vector<string> args = sml::ParseRhsArguments(pArgument)
------- Comment #2 From Douglas Pearson 2007-10-28 22:50:05 (-) [reply] ---
----
That's a good point about handling arguments with embedded spaces. Another
option rather than defining our own escape/parameter API would be to encode
the
arguments as XML and then pass the string form as the parameter. We
already
have all of the code for encoding and decoding available and this would
give us
even more extensibility than an array of strings for the long-term.
------- Comment #3 From Douglas Pearson 2007-10-28 22:52:43 (-) [reply] ---
----
I meant to also say, we could still offer a method to parse the XML back as
an
array of strings -- so the client side could still just see it in that
form.
Original issue reported on code.google.com by voigtjr@gmail.com on 23 Jul 2009 at 4:47
Original issue reported on code.google.com by
voigtjr@gmail.com
on 23 Jul 2009 at 4:47