Hi Jeff,

Thanks for the responses.  Here are a few more comments.

Even though it is a shame that the functions will not allow I/O redirection,
they are still useful.  I think I would make it a rule of my coding not to
do terminal I/O inside them.  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.

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.

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.  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

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: Monday, September 22, 2003 4:46 PM
> To: 'Jim Kramer'; [log in to unmask]
> Cc: 'Hariprasad Kodancha'
> Subject: RE: SIB item #10 - CI functions
>
>
> Hi Jim,
>
> > 1.  First, and most important, is the matter of item number 6.
> > I want to be sure I understand it.  Let's say I have a UDC named
> > UDC1 and it invokes function FUNC1 as follows:
> >
> > IF FUNC1() THEN
> > ...
> >
> > Now my understanding is that one WOULD be allowed to redirect
> > the output of UDC1,
>
> Correct.
>
> > but that then the output of FUNC1 would NOT be
> > redirected.  Is that correct?
>
> Yes.
>
> > Could one get around this as follows:
> >
> > SETVAR BOOL1 FUNC1()
> > IF BOOL1 THEN
> > ...
> >
> > That is, would the output of FUNC1 be redirected in this
> > case?
>
> No. I/O redirection is not permitted on the SETVAR command. I/O
> redirection is not supported for these commands:  IF, ELSEIF,
> SETVAR, CALC, WHILE,COMMENT, SETJCW, TELL, TELLOP, WARN and
> REMOTE. I am not sure about REMOTE since I can do this:
>    remote listf,6 >foo
> and it will create the temp file FOO on the remote box. But, the
> code seems to exclude the REMOTE command when deciding if IO
> redirection will be attempted...
>
> > If so, I think we can live with item 6, though it is obviously
> > a major restriction.
> >
> > 2.  Could a function return different types under different
> > circumstances.
> > For example:
> >
> > PARM RETURN_TYPE = "I"
> >
> > IF "!RETURN_TYPE" = "I" THEN
> >    RETURN 1
> > ELSE
> >    RETURN TRUE
> > ENDIF
>
> Yup, that's fine, and could be useful.
>
> > 3.  I think you have made a design mistake with item 7,
> > although I recognize
> > that there is an efficiency concern here.  The reason it's a
> > mistake is that
> > if a new built-in function were added to MPE, it could break
> > code that calls
> > a user-defined function of the same name.  Perhaps a call to
> > a user function
> > should look different than a call to a built-in one.  Then
> > the CI knows what to look for.
>
> I am aware of this. I spent some time deliberating on this point.
> It seems much cleaner if all function calls look the same. In
> hindsight, all HP predefined functions names should have been
> prefixed HPxxx(). I don't like the idea that a user function
> could stop working if HP added a new built-in function either, but
> I think this is the best way. Today, a new command will override
> a script of the same name. A new predefined CI variable will
> override a user defined variable of the same name.  If we were
> select user function names before predefined functions it could
> be a big mess. Think of customers that have files named WORD, INPUT,
> FINFO, MIN, UPS, etc. If these files can be found via HPPATH then
> they would be executed in place of the associated HP function. Many
> scripts that have worked correctly for years would break. I really
> think that we want stability in this design, which requires care to
> ensure as much forwards compatibility as possible. I also don't much
> like the idea of an environment variable to control the precedence
> order.
>
> > 4.  If you decide to have functions which return VOID, then
> > would you allow:
> >
> > IF FUNC1() FUNC2() FUNC3() THEN ...
> > if one of these returns boolean and the other two return VOID?
>
> Yes, that would work based on my external specs, but no IO
> redirection...
>
> > Best wishes,
>
> Thanks,  Jeff