> > Still, it would be VERY nice to overcome this
> > restriction, because it is something that will cause frustration and
> > generate support calls.  Part of me says it would be better not to do
> > functions than to do them half way.
>
> With my explanation above do you still see it this way?
>

Well, I think I am more confused than ever.

Here is the case I am concerned about.  A function contains an echo
statement with no redirection.  A command file makes use of the function in
an IF or a SETVAR.  The command file is invoked with output redirection.
What happens with the echo statement?

If it is redirected, then I don't see a serious problem.

The case you gave below does not seem to be a problem.

Best wishes,

Jim

Jim Kramer
Director of Research and Development
Lund Performance Solutions
Phone: (541) 812-7600 | Email: [log in to unmask]
Fax:   (541) 812-7612 | Web:   www.lund.com
Yahoo: jhkramer_1     | AOL:   jh kramer 1

NOTICE:  This communication may contain privileged or other confidential
information.  If you are not the intended recipient or believe that you may
have received this communication in error, please reply to the sender
indicating that fact and delete the copy you received.  In addition, you
should not print, copy, retransmit, disseminate, or otherwise use the
information.  Thank you.

> -----Original Message-----
> From: VANCE,JEFF (HP-Cupertino,ex1) [mailto:[log in to unmask]]
> Sent: Tuesday, September 23, 2003 11:04 AM
> To: 'Jim Kramer'; [log in to unmask]; 'hp3000-L'
> Cc: 'Hariprasad Kodancha'
> Subject: RE: SIB item #10 - CI functions
>
>
> Hi Jim,
>
> Again, thanks for your comments and feedback.
>
> ...
> > Even though it is a shame that the functions will not allow
> > I/O redirection, they are still useful.
>
> To be clear: the body or "code" of a user function is permitted to
> do IO redirection following the same rules that are in place today.
> But, in most cases, the invocation of the user function cannot do
> IO redirection. Example:
>
>   Filename = myFunc1
>   Contents -
>
>     PARM p1
>     echo Wish we had this sooner >tmp
>     input myVar, "This prompt "  <foo
>
>   End contents -
>
>   Invocation -
>
>   a) if myFunc(10) < 100 then  >aFile     ## will NOT work
>
>   b) if myFunc(10) < 100 then              ## correct
>
> Example a) above won't work with functions and, in fact, does
> not work today. CI commands that accept expressions do not
> support IO redirection -- the other commands do. User functions
> are most useful in expressions and that is why I wrote that in
> most cases IO redirection will not work with the invocation of
> user functions.
>
> > I think I would make it a rule of my
> > coding not to do terminal I/O inside them.
>
> Not necessary.
>
> > Still, it would be VERY nice to overcome this
> > restriction, because it is something that will cause frustration and
> > generate support calls.  Part of me says it would be better not to do
> > functions than to do them half way.
>
> With my explanation above do you still see it this way?
>
> > I believe that a call to a user function should actually look
> > different than
> > a call to a built-in function.  There is actually no benefit
> > to having them
> > look the same, and there is a benefit (both for the human
> > reader and the
> > machine interpreter) in having them look different.  And it solves the
> > problem of a new built-in function breaking existing code.
>
> We would need to invent this syntax in an unambiguous manner. I do
> see some value in being able to easily distinguish user vs. predefined
> functions from a supportability perspective.
>
> > While we are at it (!), would be very nice to add local
> > variables to user
> > commands.  A frequent concern I have in writing scripts is
> > that the command
> > I am writing will use the same variable as a calling command.
>
> Yes, this has been a long time SIG-MPE request and some work was
> done in this area. We see the effort and risk being greater than
> doing user functions, and this year it did not make the top 10+ in
> the SIB. Personally, I agree with you. I have much more need for
> local variables than for user function or global variables.
>
> > I actually
> > consider this to be a bigger need than functions: one can already have
> > "pseudo-functions" by passing variable names to a command and
> > then altering
> > the variable inside the command.  Here is an example:
> >
> >    parm var_name
> >    setvar !var_name "abc"
> >
> > Best wishes,
> >
> > Jim
>
>   Jeff

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *