> From: VANCE, JEFF (HP-Cupertino, ex1)
> 
> Jim writes:
> > I suggest that there be some kind of escaping mechanism for
> > the function name: [...]

[notes that use of HPPATH would be marginally acceptable]

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

Back up to the word "must" there and consider why you are inferring it for "...we've lost the '.' for possible methods or structure references" -- "must" you really only use the "." character for this?  Sure, it is commonly used in other languages, but does it HAVE to be the ONLY character [or character sequence] deemed "suitable" for this purpose?  Would "#" work? or how about "->" [yeah, it might confuse a C/C++ programmer, but THE COMMAND INTERPRETER ISN'T C :) :) :) ]

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

Ummm -- what about the <SPACE> character?  Surely disc space is no longer at such a premium that we have to conserve every byte possible by removing whitespace between operators...  As written, it would be function a/b/c; to get the other variants you mentioned, you would need:

   a / b/c()
   a / b / c()
 
Then again, you could tear a page out of the COBOL manual and use:

   a DIVIDED BY b DIVIDED BY c() GIVING x

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