hallidayd@yvax.byu.edu (06/29/89)
I would like to discuss operator overloading in the proposed Fortran
standard. I consider this a very important feature of the proposed
standard (in fact, this is where the ability to manipulate whole arrays
using mathematical notation, rather than DO loops, properly fits into the
language). (By the way, I **do hope** that the ability to overload
operators, and to define new dotted string operators has not been
"simplified" away. This is one of the **MOST** important features to me,
along with the type definition capability!) However, I have a few
questions, and some comments concerning its future (concerning revisions in
the next decade, or so).
First, some questions.
When overloading the relational operators (==, .EQ., <, .LT., etc.), what
restrictions are placed on the results of the new definitions? Are the
results still required to be LOGICAL? Is the definition of inequality (<>
and .NE.) automatically obtained from the definition of equality (== and
.EQ.)? Are the definitions of the symbolic relational operators always the
same as the dotted string versions, or may they be given separate
definitions? (I am sure these questions are answered in the proposed
standard, but I do not have a copy. Please, any comments will be helpful.)
Second, a few comments concerning the future of operator definition and
overlaying.
I have been using an algebraic manipulation program/language for several
years now called Macsyma. One of Macsyma's features which I have made
significant use of is the ability to define new operator symbols (including
their precedence, something which is sorely missing in the proposed
standard, but can be worked around, for now). This is one of the reasons
for my excitement upon hearing that Fortran *x was to have some of this
ability.
Macsyma not only allows the user to define new infix binary operators (like
*, /, **, etc.) and unary prefix operators (like the unary - and +, and
.NOT.), but to also define postfix unary operators (like the factorial
``!'' and double factorial ``!!'' operators) and matchfix operators (like
[array, array] and {array, array} for quantum mechanical commutator and
anti-commutator operations). This feature can truly help the mathematician
or physicist express his problem in close to natural language, rather than
having to conform to an often arbitrary seaming computer language.
In hopes that in the revision of Fortran in the next decade (to avoid
unnecessary delay of the forthcoming standard) we may have much of this
same capability (thus extending FORmula TRANslation to a greater range of
formulas, and similar concepts), I propose that we be careful about those
features we introduce in this standard which may sorely hinder the
usefulness of operator definition capabilities. The specific problem I see
at this time is the use of the exclamation point, ``!'', as an end of scan
character.
I recognize the fact that DEC's VAX FORTRAN allows the use of the
exclamation point as an end of scan character (they also use it in their
command language, DCL), and it may well be used in other extensions of
FORTRAN. However, if we are ever to allow the user to define the
exclamation point to be an operator (such as the factorial operator), as
seems desirable since it is widely used in mathematical (formula) notation,
then it must not be used for such a non-formula purpose as an end of scan
character. I agree that there is a need for some form of inline comment,
whether it is of the end of scan form (as is used by VAX FORTRAN, Ada, DCL,
LISP, APL, PostScript, TeX, Maple, in some implementations of Prolog, etc.)
or of the delimited comment form (as is used by C, Modula-2, Pascal,
Macsyma, Prolog, etc.), but let's think ahead about what we may be letting
the user in for in the future (or what we may be unnecessarily restricting
the user from).
Here is a list of some of the comment forms used by some present
programming languages and comments on whether they may be useful in the
context of Fortran, particularly with operator definition capability of the
general kind found in Macsyma (the only language that allows such
definition to go beyond overloading predefined operators---Ada's
restriction):
Comment Type of Some representative Comments concerning
Delimiter delimiter languages applicability
---------------------------------------------------------------------------
! end of scan DCL, VAX FORTRAN Will preclude its use for
factorial
% end of scan PostScript, TeX May be useful as comment
sometimes Prolog character, but some users may
desire it for its definition
for percentages
; end of scan LISP It is quite obvious we should
not use this in Fortran (at
least so long as we desire
multi-statement lines---I do)
# end of scan Maple May be useful as comment
character, I don't see that we
need it for .NE. since we have
<>. There could, possibly, be
a sufficient desire/need for
this as an operator
***Comments please***
-- end of scan Ada May be useful, though I can
foresee a _possible_ desire for
this operator (along with ++)
for interval types---taking the
difference of two intervals,
rounding both differences the
same way (as opposed to the usual
treatment for interval types).
Is this sufficiently unlikely?
***Comments please***
/* */ delimited Prolog, Macsyma, May be useful. This would mean
and C that if the asterisk was given
a prefix or postfix definition
a space would need to be used
between it and the slash
operator. (Should not be a
real hardship, we will probably
be going more for the free form
for Fortran programs by then.)
(* *) delimited Pascal, Modula-2 May be useful. (Similar
comments as for the above.)
Or is this delimiter pair
already being used in Fortran
(for array constructors, for
machines without square
brackets, or am I thinking of
another delimiter pair like
(| |) or such)?
{ } delimited Pascal Would preclude their use for
the quantum mechanical anti-
commutation operation (just
as the use of square brackets
precludes their use for the
quantum mechanical commutation
operation)
---------------------------------------------------------------------------
I realize we cannot make everyone happy, but let's not unnecessarily
preclude the use of widely used mathematical operators by making hastily
thought out decisions, such as the use of the exclamation point as an end
of scan character. I further realize that there is no need for Fortran to
use a comment character form that has any resemblance to those used by any
other language, but at the same time, if the form used by another language
can suit our purposes, why invent another?
As I see it, the best choice for an end of scan type comment delimiter is
something like the double dash used in Ada. It is at least as easy to type
on most keyboards I have seen as the ``!'' key (which is shifted, while the
dash is not). An extension of this form, such as the triple dash (often
found in these postings to represent the typographical m-dash) would be
even less likely to be used as an operator, but is not as clean as the
double dash and is harder to type.
As for delimited comment forms (a form I personally prefer, partly for the
ease with which code can be commented out using this form), I would expect
the (* *) form to be the cleanest and not very likely to cause
interference with future operator definitions (unless it is already being
used in Fortran 8x, in which case I would go for my second choice /* */,
or some other form of delimiter pair (maybe {* *}, if most systems have
curly brackets, as their extensive use in C would suggest)).
Just some thoughts. Please comment freely. We want Fortran to be the best
it can be, do we not?
_____________________________________
/ David Halliday \
| |
| Internet: hallidayd@yvax.byu.edu |
| BITNET: hallidayd@byuvax |
| Us Mail: BYU Physics Department |
| 296 ESC |
| Provo, UT 84602 |
\_____________________________________/hallidayd@yvax.byu.edu (06/30/89)
In my posting (message <666hallidayd@yvax.byu.edu>) I stated: >Here is a list of some of the comment forms used by some present >programming languages and comments on whether they may be useful in the >context of Fortran, particularly with operator definition capability of the >general kind found in Macsyma (the only language that allows such >definition to go beyond overloading predefined operators---Ada's >restriction): > >Comment Type of Some representative Comments concerning >Delimiter delimiter languages applicability >--------------------------------------------------------------------------- >... >% end of scan PostScript, TeX May be useful as comment ^^^^^^^^^^^^^ > sometimes Prolog character, but some users may > desire it for its definition > for percentages I forgot that ``%'' is used as the structure field selection operator, so we certainly cannot use it as an end of scan character.
dik@cwi.nl (Dik T. Winter) (08/08/89)
In article <666hallidayd@yvax.byu.edu> hallidayd@yvax.byu.edu writes: >Here is a list of some of the comment forms used by some present >programming languages and comments on whether they may be useful in the >context of Fortran, particularly with operator definition capability of the >general kind found in Macsyma (the only language that allows such >definition to go beyond overloading predefined operators---Ada's >restriction): > Note that also Algol 68 allows general operator definition (in fact the number of potential operators in Algol 68 is infinite). -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax