9 Jan 1997 21:57:48 -0500

Related articles |
---|

[19 earlier articles] |

Re: User definable operators adrian@dcs.rhbnc.ac.uk (1997-01-02) |

Re: User definable operators hrubin@stat.purdue.edu (1997-01-02) |

Re: User definable operators anw@maths.nottingham.ac.uk (Dr A. N. Walker) (1997-01-03) |

Re: User definable operators WStreett@shell.monmouth.com (1997-01-03) |

Re: User definable operators apardon@rc4.vub.ac.be (1997-01-07) |

Re: User definable operators icedancer@ibm.net (1997-01-07) |

Re: User definable operators wclodius@lanl.gov (William Clodius) (1997-01-09) |

From: | William Clodius <wclodius@lanl.gov> |

Newsgroups: | comp.compilers |

Date: | 9 Jan 1997 21:57:48 -0500 |

Organization: | Los Alamos National Lab |

References: | 96-12-088 96-12-163 96-12-181 96-12-185 97-01-01596-12-088 96-12-163 96-12-181 96-12-185 97-01-015 97-01-028 |

Keywords: | syntax, design |

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]

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.