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 *