i think it's desireable to have user functions behave as predefined ones.

i don't agree with the statement that "user functions are basically scripts or UDCs which return a value via their name."  fundamentally, yes this is true but i view a function -- whether user-written or hp-supplied -- as a building block or a tool.  because functions are inheiritantly meant to be general purpose, they need to be able to handle the format of their parameters (pretty much) however they're delivered.  since i can already pass   5-1    to a hp-supplied function and know that it'll be evaluated to 4 immediately, my expectation and desire is be able to do the same to my own functions.      - d

----- 
Donna Hofmeister, HP-CSA Sr. System Programmer
dgarverick -at- longs -dot- com
925-210-6631 Longs Drug Stores
 
>>>MY opinions, not Longs Drug Stores'<<


----- Original Message ----
From: "Vance, Jeff H (Cupertino)" <[log in to unmask]>
To: [log in to unmask]
Sent: Thursday, November 9, 2006 9:20:57 AM
Subject: Re: [HP3000-L] opinion on CI User function parameters


> -----Original Message-----
> Functions are functions whether they are user or predefined.
> We are all used to the rules when using predefined functions.
> Why have user functions work differently?
> 
Agreed and that is why user functions are currently coded to evaluate
parameters. There is a bug in our logic and that's why we are looking at
user function parms again. User functions are new and installed by only
a few customers.

However, I wrote below, and I believe it to be true, that user functions
are basically scripts or UDCs which return a value via their name.
Scripts and UDCs do not (and have never) evaluated their parameters.
Thus the dichotomy.

To help folks on the fence on this topic, I believe that if we do NOT
evaluate user function parms, i.e. treat them the same as UDCs and
scripts, then the user can always force evaluation if that's their
desire. On the other hand, I think there can be problems if we evaluate
user function parms automatically.

For instance, assume this user function:
  PARM p1,p2
  echo p1=!p1, p2=!p2
  return "!p1!p2"

Here are some uses where we DO evaluate user function parms:

1) :calc test(a,b)
Variable name encountered, but variable is not defined. (CIERR 9805)

This is because A and B are not defined variables, but this works as a
script:
   :test a b
   p1=a, p2=b

2) :calc test("a","b")
   p1=a, p2=b
   ab 

So for the user functions we need to quote string values (as required by
the predefined functions).

3) :calc test("a","b c")
   test a,b c
   Too many parameters were given for this command. (CIERR 10002)

This should work, and, in fact, is the bug we're addressing. We get this
error because there are now TWO levels of evaluation being performed.
First, we evaluate parms when parsing the user function parameter list.
Then we pass the function and it's (evaluated) parameters to the CI to
be executed. In example 3 this is what the CI sees after the user
function code is complete:
   test a, b c

Since spaces are UDC/script parm delimiters the CI correctly reports a
too many parms error.


I'll check email later tonight as I am leaving for GHRUG in 15 minutes!

Jeff Vance, vCSY


> -----Original Message-----
> >User functions are basically UDCs or scripts which return a 
> >value via their name, when invoked.
...

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



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