Jim writes:
> I really think it is too restrictive not to be able to qualify
> a function name.  It is certainly unlike command files.
>
> I suggest that there be some kind of escaping mechanism for
> the function name:
>
>   f()
>   "f.b.a"()
>   "/A/B/F"()
>
> Quotes might not be the best escape character.  I'm not sure.

It would be real tough to get quotes to be an escape character
since they enclose string values also. The parenthesis and lack
on intervening operator would need to be the clues but the evaluator's
parser does not support this much lookahead. Maybe square brackets, but
they also allow quotes inside...

> You asked for an example.  Our installation scripts are
> command files that
> run on customer systems.  They reside in the LPS account and
> are run from
> the SYS account, so we fully qualify the names of other
> command files that
> are in the LPS account.  We would want to do the same for CI
> functions that we might use.

Is it an acceptable option to prepend "LPS," to HPPATH during the
install and then remove it afterwards?

> Yes, we could put the name of the group containing our
> command files at the head of the HPPATH list, and it would work.

My lookahead was too small also! :)

> But we shouldn't HAVE to do it that way, one should be able to name
> a function anywhere on the system without having to have the HPPATH
> variable point to its location.  Where else in MPE must a file be on
> the path in order to use it?

Fair question. I believe the answer is nowhere else, given the word
"must" above. Even with Jim's good arguments I have this feeling that
90+% of the use of user written functions will not be qualified. If
we allow qualified names then we've lost the "." for possible methods
or possible structure item references. Sure, this enhancement is not very
likely and there could be some creative escaping but it will be ugly.
Also, I don't like the idea of qualified MPE names but not qualified
POSIX name. So unless we allow "/" to be interpreted in different ways
we cannot parse qualified POSIX names. As an example:

   setvar x a/b/c()

Does X get set to the return of the function "a/b/c", or to A divided by
the return of the function "b/c", or to A divided by B which is divided
by the return of the function "c"?  Without some way of escaping or other-
wise designating that the "/" is not the division operator, we cannot
support "/" in a filename (in the evaluator).

My thoughts,
 Jeff

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