sleyzerzon / soar

Automatically exported from code.google.com/p/soar
1 stars 0 forks source link

add exec-like RHS function that automatically puts spaces between args #26

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago

Original comment by voigtjr@gmail.com on 23 Jul 2009 at 5:29

GoogleCodeExporter commented 9 years ago

Original comment by voigtjr@gmail.com on 23 Feb 2010 at 7:43