Re: User definable operators

As the one who started this thread I have decided that it would be
useful to give some background. As some of you may know, I have an
interest in the Fortran standardization process and would like to
develop appropriate comments on some current proposals.


Of primary interest to this thread is a proposal to add interval
arithmetic to the Fortran standard. (Note: interval arithmetic
attempts to find a bounded interval containing the solution to a
problem, instead of a single approximate value whose error is unknown.
It is expected that having this capability in the language will result
in more reliable software.) Most of the definition of an interval
arithmetic type is straightforward, however the number of arithmetic
and relational operations for an interval type are significantly
larger than for the standard scalar types. Further, most of these
additional operations have semantics similar to the standard
arithmetic operations (particularly the relational operations). It is
therefore desirable to be able to associate operators with these
operations, and assign precedences to these operators that are the
same as those of the standard operators they most resemble.


The language as it currently exists allows the overloading of its
standard operators, which retain their standard precedences, and
allows users to define their own operators using a syntax similar to
that of the standard .EQ., .LE., ... operators. However, user defined
operators currently have a specific arity defined precedence, the
highest possible precedence, if they are unary, or the lowest possible
precedence, if they are binary. The language as it currently stands
does not allow user defined operators with the same precedences as the
standard operators. Therefore, as I see it the language faces the
following choices


1. Forget about interval arithmetic


2. Include interval arithmetic, but define operators only for those
operations that almost exactly match the standard arithmetic
operations.


3. Include interval arithmetic, define operators for all operations
of interest, but require all operators that do not match intrinsic
operators to have the default precedences of user defined operators.
This, particularly for the relational operators, would be
non-intuitive to the more knowledgeable users of interval arithmetic.


4. Include both interval arithmetic, user defined operator
precedence, and renaming on USE of user defined operators from
modules. (Renaming would be necessary to deal with name conflicts for
operators at different precedence levels, but could also be useful in
its own right). This might be error prone in that users would have to
remember the precedences of the new operators as well as other aspects
of the operators. The interval arithmetic problem suggests that
precedence specification only in terms of existing precedences would
be acceptable (the proposed non-standard interval operators would use
only three levels, *, binary +, and relational).


5. Make interval arithmetic a special case and define intuitive
precedences for all its operators. I don't think anyone will accept
this. What happens later if someone wants to add diadics, rational
arithmetic, matrix operators, etc. to the language?


6. Add additional operator symbols to the language (e.g., @, #, ^,
etc) at the same precedence levels as the current operators. This is
liable to cause opposition in the ISO (international) arena, as
Fortran is one of the few languages that can be easily coded on almost
any keyboard (no one seems to like C's triglyphs and diglyphs).


7. Allow one user defined precedence level, RELATIONAL. This is the
most intuitive of all the precedence levels and includes more than 80%
of the desired additional operators. The other two operators might
then be addressed in any of several ways, e.g., via the addition of
symbols to the language, by letting the operators have the default
precedence, or by providing their capabilities in a functional form.


(Note: Those interested in the details of the interval arithmetic
proposal might want to examine
ftp://ftp.ncsa.uiuc.edu/x3j3/meeting139/96-156.txt.gz
and related subsequent papers
ftp://ftp.ncsa.uiuc.edu/x3j3/meeting139/96-166.txt.gz
ftp://ftp.ncsa.uiuc.edu/x3j3/meeting139/96-171.txt.gz
ftp://ftp.ncsa.uiuc.edu/x3j3/meeting139/96-173.txt.gz
ftp://ftp.ncsa.uiuc.edu/x3j3/meeting139/96-173.txt.gz
)


I would be interested in comments on or alternatives to the above.


In addition to the above precedence issue, the language is also
considering allowing user defined operators and functions that, for
pointer arguments, allows modification of the arguments. This is is a
substantive change in the language semantics that is being driven by
the desire for optimization and the experience of many with C++ code
where such flexibility is used to optimize code. I would be
interested in possible alternatives to this change (or restrictions on
this change) in operator and function semantics, as I supect that such
an addition to the language would make it more error prone and
non-intuitive.
--
William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: wclodius@lanl.gov
[If there's no obvious precedence for these operators, don't give them one,
and require parentheses when they're used in combination with anything else.
This is technically very easy to implement, and avoids a lot of the wierd
bugs you get with C's billions and billions of precedence levels. If you
want to let people define new operators, make them spelled .XXXX. where the
XXXX has to be different from any existing operator like .NE. -John]


--

Return to the comp.compilers page.
Search the comp.compilers archives again.