Hi all,

Way back we said that we were going to implement "CI Functions",
which is one of the top 10 2003 SIB items.

John Burke was careful in the wording of this SIB request:

  "...the ability to call another script or UDC as a function that
  would return a value using an enhanced CI RETURN command...."

This means, to me, that we are not going to implement library functions,
where binary user code is executed by the CI.  It also means, to me,
that we are not going to implement sub-routine functions inside of the
same script/UDC, like are provided by the POSIX and other shells.

Here is how I see this request, from an external perspective.

1. the function returns a value, which can be a string (limited by
the value size of a CI variable to 1024 bytes), Boolean, or signed
32 bit integer, in place of its name and arguments.

2. the function value will be returned via the CI's :RETURN command,
which will have an optional expression arg added.

3. a function that does not explicitly return a value will either be
an error (dislike), or will be void (prefer).  A void function would
simply be executed inline and erased from the command line image.

4. a user function is located via the same mechanisms used to locate
UDCs and command files/scripts. That is, HPPATH is used to find scripts
and the UDC directory is used to find UDCs. UDCs have precedence over
scripts of the same name. A script could invoke UDC and script functions.
A UDC could do the same.  Option RECURSION UDCs would cause the search
to start over at the beginning of the UDC catalog. "NoRecursion" UDCs,
which are the default, would start from where the current UDC resides
(in file order and user, account, system order).

5. a script or UDC can invoke itself as a function and today's nesting
limits will apply.

6. (sadly) I/O redirection will not be supported for many function
invocations. This is because the CI does not perform I/O redirection
on the most important commands involved with expression evaluation,
such as: if, elseif, while, setvar, calc.

7. function precedence order is that predefined functions take
precedence over user defined functions. So, if you define your own
"string" function, you need to name it some other name besides "STR",
since the CI will always execute the built-in str() function.

8. user function names follow the same rules as UDC and script
names as far as legal characters and the length of the name.


Some examples:

a. if my_function(a,b,c) > 5 then

b. if rht(strng,-3) <> "A" and usrFunction() then
       # usrFunction returns a Boolean true or false

c. while word(usrGetInput("prompt")) <> "" do

d. echo ![Get_reply()] ABC.   # function without parms, or
                                using default parms

e. echo ![update_file(1,2,3)]ABC   # will display only ABC
       # void user function

f. if true and update_file(1,2,3) then  # cierr 9940,
       # void user function             # non-bool expr found

g. if myfunc.grp.acct(1,2,3) = "ab" then
       # qualified function name, HPPATH not used

h. if /usr/funcs/myFunc.f(1,2,3) = "ab" then
       # qualified function name, HPPATH not used

i. if ./funcs/myFunc.f(1,2,3) = "ab" then
       # qualified function name, HPPATH not used



Myself and Hariprasad, the engineer from Bangalore that will be
implementing this new feature, encourage your feedback on the
external characteristics and assumptions above.

Regards,
 Jeff Vance, vCSY

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