Hi Glen,

On Nov 15, 12:50pm, [log in to unmask] wrote:
> Subject: Enhancement request: QUOTE() in CI (long)
snip...

> The basic problem is that UDC and command file parms are not first-class
> variables. This most frequently (in my experience) comes into play with
> ANYPARM, which passes the full string to the UDC or command file
snip...

> To get around all this, it seems there are two solutions:
>
>         1. Make UDC (and command file) parms first class variables
>         2. Implement quote()
>
> The first solution is probably a lot of work. The second MAY be much
> easier. (Jeff? Off the top of your head...?)

Well, after the "global var" meeting this week, where a small group
brainstormed the best design for global and local vars, it appears *likely*
(but not guaranteed) that script parms will be able to be dereferenced
like true vars.. In fact, script-local (called PRIVATE) vars can be
implememted internally exaclty like parms.  I don't know for sure if this
will actually happen, but this is what I will be proposing.  And there is
a downside: today you can have a jobses var and a parm of the same name,
say foo.
   echo !foo    <-- references the parm
   if foo ...   <-- references the jobses var.

When private vars are the same as parms this also means that parms are
the same as private vars, and thus the "if foo..." line also references
the parm.  this is nice and consistent and also backwards incompatible.
Can you live with this??

> quote() would allow us to 'quote' the parm without having to specify a
> fixed quote character. For example, our 'if' test could be
>
>         if quote(!parm) = "~"
>
> The one stickler here is whether or not blanks inside the parens are
> significant. For example, how should
>
>         quote( !parm )
>
> be evaluated? Should the blanks on either side of "!parm" be part of the
> resulting string?

Or worse yet, what if the value of "parm" contains a right parenthesis??
I think there is value to a quoting function but for it to always work
its argument cannot be explicitly dereferenced.

> This has been a constant source of frustration. If there is a solution in
> 5.5, then, to quote Roseann Rosannadana, "never mind." (I haven't see the
> Communicator for this, so I cannot check.)

No 5.5 solution...sorry.

Thanks for the good suggestions.

Jeff Vance, CSY

--