I've been playing with function parms some more, and found something quaint
with parms like "true" & "false".

Here's my test command file.  The commented-out lines may be informative or
just clutter, depending on your preferences.  The "calc" command without the
quotes (line 4) gives an error on some inputs.

:print tester
PARM p1
echo p1=!p1;  length = ![len("!p1")]
continue
# calc !p1
calc "!p1"
# setvar   t1  typeof(!p1)
# setvar   t2  typeof("!p1")
# setvar   x   "invalid,integer,string,boolean"
# echo parm 1 type = !t1 ![word(x,,!t1 + 1)] (without quotes)
# echo parm 1 type = !t2 ![word(x,,!t2 + 1)] (quoted)
return   "!p1"


If you calc with quotes around the parm (as shown above, line 5):
:tester true
p1=true;  length = 4
true
:calc tester(true)
p1=1;  length = 1
1
1
The non-function parm is a 4-byte string, but in the function it gets
converted to a number!  Almost predictable if you think about how booleans are
stored and what might happen if a parm is evaluated twice, but that doesn't
mean I have to like it.

When I change the "calc" to not use quotes:
:tester true
p1=true;  length = 4
TRUE
:calc tester (true)
p1=1;  length = 1
1, $1, %1
1
The non-function ("dysfunction" ?) parm becomes boolean (as you can see
because the calc says "TRUE" instead of "true"), but the function still gets a
digit.

Now, back to the calc with quotes (because without quotes there is an error).
:tester " a "
p1= a ;  length = 3
 a
:calc tester (" a ")
p1=a;  length = 1
a
a
This is just a clearer example of the issue in my prior post, where the length
changes as leading & trailing blanks get chopped off the parms for a function.

In all those examples, I think the non-function seems more "correct".  I've
tested other cases and not found anything where the function seemed better.
So I still vote for treating user-functions more like non-function command
files (meaning NOT evaluating user-function parms up-front).


The original question was posed as "either treat user function parameters like
the other predefined function parameters, or like UDC/script parameters", and
I get the impression that most other responders think all functions should be
handled the same, whether "user" or "predefined".
The problem is, even if HP tries to make them the same, it won't always work
that way because in a user function, the parms get evaulated again by the
separate commands in the function, and the double-evaluation can change the
results.
I think some of you might answer differently if the question were re-phrased
"should any parm ever get evaluated twice before it gets to an individual MPE
command?".  AFAIK, that only happens in user functions.

Also, my wild guess is that the original bug (where a parm like "a b" gets
treated like two separate parms in a user-function), would be easier for HP to
fix by just eliminating the fine-print to evaluate parms when a user function
is called, rather than try to enhance it to handle every special case in some
reasonable manner.

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