Maybe the answer lies in the details.  If one wants the value to be 
evaluated then the user can code to set the new value up front. 
Otherwise leave the parameter as is and let it be evaluated when needed.

Olav.

Miller, Keven wrote:

> It takes me a few days to let all this sink in.
> And maybe in the past this was discussed.
>
> First, I prefer to have them evaluated, as the built-in functions.
>
> One conflict I see is knowing which way to evaluate.
> Lets use Jeff's previously defined user function:
>
> Filename 2 = FUNC.PUB.SYS
> -------------------------
> PARM p1
> echo p1=!p1
> return !p1*(!p1-1)
>
> When used as a function, we know how its invoked, and can use the
> (being discussed) defined behavior.
>
> :SETVAR X FUNC(5-1)
> p1=4
> :SHOWVAR X
> X = 12
>
> But if called as a command file, the system doesn't know its a
> function until it scans a "return value" statement. What the
> defined behavior is, I don't know. Either an error on the
> return statement or the var HPRESULT gets set. But the point is
> you could get a different value as a script than as a function.
>
> :FUNC (5-1)
> p1=5-1
> CIERROR    return value in a script
>
> or
>
> :FUNC (5-1)
> p1=5-1
> :SHOWVAR HPRESULT
> HPRESULT = 2
>
>
> Maybe we just need an OPTION FUNCTION at the start telling MPE how to
> interpret the parms. So when used as a script, it can evaluate the parms.
>
> Filename 3 = FUNC2.PUB.SYS
> -------------------------
> PARM p1
> OPTION FUNCTION
> echo p1=!p1
> return !p1*(!p1-1)
>
>
> Keven
>
> * 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 *