I believe this reply of mine only went to OpenMPE.  Jeff

-----Original Message-----
From: VANCE,JEFF (HP-Cupertino,ex1) [mailto:[log in to unmask]]
Sent: Monday, September 22, 2003 5:46 PM
To: [log in to unmask]
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

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