Hi Dave,

Thanks for your research!

> -----Original Message-----
> I've been playing with function parms some more, and found 
> something quaint with parms like "true" & "false".
...
> :tester true
> p1=true;  length = 4
> true
> :calc tester(true)
> p1=1;  length = 1
> 1
> 1

Thanks! You found a bug. The evaluated parameter should simply resolve
to the string "TRUE" (as it does when you invoke :calc !p1).

> 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.

Yes, one interpretation is as you wrote above, but the code is supposed
to return the string equivalents of TRUE and FALSE.  E.g.
  :tester 1=1
  p1=1=1;  length = 3
  1=1
  :calc tester(1=1)
  p1=1;   length = 1
  1
  1

Without this bug you'd get:
  :calc tester(1=1)
  p1=TRUE;   length = 4
  TRUE
  TRUE

...
> 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".

So far is about even -- maybe just slightly more prefer user function
parms to behave like the predefined function parms.

> 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.

Exactly!

> 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?".  

I think you'd a majority of NO's here, but, in fairness, no one said
they wanted us to evaluate parms twice. That happens to be our
implementation since it was easiest for us, with the lowest risk, and
the fewest code changes (and it is still a fair amount of new code).

> AFAIK, that only happens in user functions.

Correct.

> 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.

Absolutely!

Thanks,
 Jeff 

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