Fortran - Precedence

Author

Precedence

David Ham

2005-01-25, 8:57 am

On Mon, 24 Jan 2005 18:47:27 GMT
Dick Hendrickson <dick.hendrickson@att.net> wrote:

>
>
> The major hang-up seems to be the precedence for the new
> operators. Various reasonably convincing (as opposed to
> absolute mathematical proof) arguments have been made for
> highest, lowest, same as AND or OR, and one below (or maybe
> above) AND or OR (at least that's what I recall). I don't
> want to reargue the arguments here. It's just that people,
> who in other circumstances appear intelligent ;), come to
> different conclusions. There's also the concern that
> Fortran has a ton of precedences and that no normal
> human being can remember if .NEQV. is above or below
> .EQV.. Adding a couple of more to the list is unlikely
> to improve ;) .
>

On the subject of precedence, although I concede at a significant
tangent to the thread, I'd really like to see the ability for defined
operators to be given a precedence other than the lowest available.

As someone else pointed out, it is a significant help that all the
intrinsic maths operators in Fortran have the mathematically expected
precedence. Unfortunately, if you define an operator it is not possible
to give it a likewise expected precedence. In particular I, as I'm sure
many others do, tend to define operators to do some of the other forms
of multiplication which are possible on matrices and vectors. In the
particular case of the .dot. product, the fact that you can add a scalar
to a vector makes a + b .dot. c a particularly nasty trap. It'd be nice
to do something like:

interface operator (.dot.) precedence(*)
module procedure ...
end interface

Of course there are subtleties (aren't there always) like what happens
if .dot. is defined somewhere else as well but it might be possible to
make it work.

There is an argument against doing this which is that in the current
situation a programmer can tell the order of operations in an expression
just by reading it while under my proposal (s)he would have to check
definitions but IMHO the confusion caused by having operators with
different precedence to their normal mathematical precedence is worse.
In addition, there are quite a lot of other things that you can't tell
about an expression without reading the variable and operator
definitions so this doesn't create a new class of difficulty.

Regards

David

Dick Hendrickson

2005-01-25, 4:00 pm

David Ham wrote:

> On Mon, 24 Jan 2005 18:47:27 GMT
> Dick Hendrickson <dick.hendrickson@att.net> wrote:
>
>
>
>
> On the subject of precedence, although I concede at a significant
> tangent to the thread, I'd really like to see the ability for defined
> operators to be given a precedence other than the lowest available.
>
Well, technically unairy operators have the highest
precedence, so I guess you can do what you actually asked
for ;) .

Seriously, this has come up several times at X3J3 meetings
and the response from compiler developers/vendors has always
universally been that they'd kill themselves if that were
put in. (That's probably OK in a couple of cases, but not
a good general solution ;) ). The problem is in the way
the parsers/lexers are designed for Fortran. There is just
no good, commercially feasible, efficient, way to add new
operators "randomly" into the middle of current production
grade parsers. As I understand it, it's not that it can't
be done (Turning solved that one), it's that current parsers
are tied to the optimizers and/or code generators in ways
that just make it totally impractical.

You can overload existing operators and then they keep
their precedence. But, changing .dot. to * also has
a serious human readability problem.

Dick Hendrickson

> As someone else pointed out, it is a significant help that all the
> intrinsic maths operators in Fortran have the mathematically expected
> precedence. Unfortunately, if you define an operator it is not possible
> to give it a likewise expected precedence. In particular I, as I'm sure
> many others do, tend to define operators to do some of the other forms
> of multiplication which are possible on matrices and vectors. In the
> particular case of the .dot. product, the fact that you can add a scalar
> to a vector makes a + b .dot. c a particularly nasty trap. It'd be nice
> to do something like:
>
> interface operator (.dot.) precedence(*)
> module procedure ...
> end interface
>
> Of course there are subtleties (aren't there always) like what happens
> if .dot. is defined somewhere else as well but it might be possible to
> make it work.
>
> There is an argument against doing this which is that in the current
> situation a programmer can tell the order of operations in an expression
> just by reading it while under my proposal (s)he would have to check
> definitions but IMHO the confusion caused by having operators with
> different precedence to their normal mathematical precedence is worse.
> In addition, there are quite a lot of other things that you can't tell
> about an expression without reading the variable and operator
> definitions so this doesn't create a new class of difficulty.
>
> Regards
>
> David

Ron Shepard

2005-01-25, 4:00 pm

In article <20050125114043.77dd9ac8.d.a.ham@citg.tudelft.nl>,
David Ham <d.a.ham@citg.tudelft.nl> wrote:

> There is an argument against doing this which is that in the current
> situation a programmer can tell the order of operations in an expression
> just by reading it while under my proposal (s)he would have to check
> definitions but IMHO the confusion caused by having operators with
> different precedence to their normal mathematical precedence is worse.

Another option that might be useful would be the ability to define
operators that have no precedence. Such operators would require
explicit parentheses to define the order of operations. If the
parentheses aren't there, then a compile-time error would tell the
programmer what needed to be corrected.

$.02 -Ron Shepard

David Ham

2005-01-25, 4:00 pm

On Tue, 25 Jan 2005 16:02:18 GMT
Dick Hendrickson <dick.hendrickson@att.net> wrote:

>
>
> David Ham wrote:
>
> Well, technically unairy operators have the highest
> precedence, so I guess you can do what you actually asked
> for ;) .
>
> Seriously, this has come up several times at X3J3 meetings
> and the response from compiler developers/vendors has always
> universally been that they'd kill themselves if that were
> put in. (That's probably OK in a couple of cases, but not
> a good general solution ;) ). The problem is in the way
> the parsers/lexers are designed for Fortran. There is just
> no good, commercially feasible, efficient, way to add new
> operators "randomly" into the middle of current production
> grade parsers. As I understand it, it's not that it can't
> be done (Turning solved that one), it's that current parsers
> are tied to the optimizers and/or code generators in ways
> that just make it totally impractical.

Oh, that's unfortunate. It also seems rather odd but I don't know enough
about parsers to pass comment on this limitation.

>
> You can overload existing operators and then they keep
> their precedence. But, changing .dot. to * also has
> a serious human readability problem.

And it's also illegal in the obvious case where it would be useful since
you can't overload an operator if its already defined for those
arguments.

You can, however, overload * for matrix vector multiplications and we do
that.

David

>
> Dick Hendrickson
>
>

David Jones

2005-01-25, 4:00 pm

David Ham wrote:
> On Tue, 25 Jan 2005 16:02:18 GMT
> Dick Hendrickson <dick.hendrickson@att.net> wrote:
>
>
> Oh, that's unfortunate. It also seems rather odd but I don't know
> enough about parsers to pass comment on this limitation.
>
But can't the problem be solved by having a pre-full-parsing parsing
phase where the code is modified by inserting parentheses so that the
"right" precendence is achieved?

James Giles

2005-01-25, 8:59 pm

David Ham wrote:
> On Tue, 25 Jan 2005 16:02:18 GMT
> Dick Hendrickson <dick.hendrickson@att.net> wrote:
....
>
> Oh, that's unfortunate. It also seems rather odd but I don't know
> enough about parsers to pass comment on this limitation.
....

Actually, it's that parsers are separated from code generators and
other parts of the compiler in ways that make such a feature difficult.
A language in which operators have definable precedece does not
have a context free syntax. That's a problem. It can be solved
by having the parser sort of rewrite itself in each scoping unit. Or
it can be solved by having some of the parser's actions controlled
by semantic information in the context. Both are hard solutions
to adopt.

I've written a preprocessor that allowed user defined operators
with user defined precedence. I won't say anything more about
the difficulty of the implementation. I'd rather point out that the
*use* of the feature has negative impact on the legibility and
reliability of code. The same thing that makes it hard for compilers
also makes it hard for humans to read. But, whereas compilers
have a perfect memory for the definitions of the operators, humans
tend not to. Indeed. I had trouble reading my own sample codes
that demonstrated the feature. Once you forget the precedence
and associativity you assigned an operator you can't read code
using it (well, unless it's the only operator in the expression - but
then the precedence is irrelevant).

Then there's the problem that different people may define the same
operator, you may even be lucky and they'll give it the same meaning,
but with different precedence. How would you like to maintain a code
containing some procedures from each of those developers? They'd be
*almost* consistent. You would always have to remind yourself where
each code came from. Or, indeed, would you even notice they *weren't*
consistent until sometime later?

One thing that might be done is to introduce several more operators
at the existing precedence levels in the language that have no intrinsic
operations associated with them. So, let's say that ^ has the same
precedence as **, but no intrinsic meaning. You can overload that
operator to mean what you like. But, its precedence remains obvious
to anyone that sees it, since it's consistent throughout the language.
Or, let's say that # has the same precedence as + and -. The problem
with this possibility is that few operator-like characters remain in the
implementation character set that haven't been used for something else.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Duane Bozarth

2005-01-25, 8:59 pm

James Giles wrote:
,,,
> One thing that might be done is to introduce several more operators
> at the existing precedence levels in the language that have no intrinsic
> operations associated with them. So, let's say that ^ has the same
> precedence as **, but no intrinsic meaning. You can overload that
> operator to mean what you like. But, its precedence remains obvious
> to anyone that sees it, since it's consistent throughout the language.
> Or, let's say that # has the same precedence as + and -. The problem
> with this possibility is that few operator-like characters remain in the
> implementation character set that haven't been used for something else.

It would seem this would also introduce a real difficulty in adapting
others' code that had other definitions for the same operator
characters...

John Harper

2005-01-25, 8:59 pm

In article <e4uJd.86338$w62.48089@bgtnsc05-news.ops.worldnet.att.net>,
Dick Hendrickson <dick.hendrickson@att.net> wrote:
>
>Seriously, this has come up several times at X3J3 meetings
>and the response from compiler developers/vendors has always
>universally been that they'd kill themselves if that were
>put in.
(reasons deleted)
>
>You can overload existing operators and then they keep
>their precedence. But, changing .dot. to * also has
>a serious human readability problem.

Not to mention leaving .cross. out in the cold.

Maybe it's time to go back to Algol 68, in which users could
specify their own precedence for defined binary ops.

John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

James Giles

2005-01-25, 8:59 pm

Duane Bozarth wrote:
> James Giles wrote:
> ,,,
>
> It would seem this would also introduce a real difficulty in adapting
> others' code that had other definitions for the same operator
> characters...

Of course that problem exists for operators as presently supported in
the language. This is a problem, but it's a problem independent of how
the precedence of user defined operators is resolved.

Frankly I've come to the conclusion that users should be encouraged
not to define any operators unless they have the same algebraic properties
as existing operators or have *very* well understood conventional meanings.
So you shouldn't overload + unless your new type is numeric and the +
operator is used for addition. Same with * or / or - or **. Quaternions
come to mind as a reasonable feature. The same with rationals. With
only a very few exceptions I don't think defined operators (or overloaded
operators) add much to the legibility of code. But, you can't outlaw them
altogether since they really are an improvement in those rare instances.
The only solution I can think of is training.

Now, if the implementation character set were extended to ISO Latin-1,
we would have additional operators available. So, for matrices, trensors,
vectors, and the like we could use * as elemental multiply, · (centered dot)
as matrix multiply and/or dot-product, and × as cross product. That
would, I think, satisfy the needs of the original article in this thread.
We
could even distinguish integer divide (the / operator with two integer
operands)
from rational construction (the ÷ operator with two integer operands).
All these should have the same precedence as multiply and divide. Since
MATRIX, VECTOR, TENSOR, RATIONAL, and the like are not intrinsic
types, the additional operators would not have any intrinsic meaning
defined.

(Note: if the symbols in the last paragraph don't make sense, you may have
a non-standard browser or have non-standard defaults set. The default
character set for USENET communications, if no other is mentioned in
the headers of a message, is supposed to be ISO latin-1.)

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

beliavsky@aol.com

2005-01-26, 3:59 am

James Giles wrote:

> Now, if the implementation character set were extended to ISO
Latin-1,
> we would have additional operators available. So, for matrices,
trensors,
> vectors, and the like we could use * as elemental multiply, =B7
(centered dot)
> as matrix multiply and/or dot-product, and =D7 as cross product. That
> would, I think, satisfy the needs of the original article in this
thread.
> We
> could even distinguish integer divide (the / operator with two
integer
> operands)
> from rational construction (the =F7 operator with two integer
operands).
> All these should have the same precedence as multiply and divide.
Since
> MATRIX, VECTOR, TENSOR, RATIONAL, and the like are not intrinsic
> types, the additional operators would not have any intrinsic meaning
> defined.
>
> (Note: if the symbols in the last paragraph don't make sense, you may
have
> a non-standard browser or have non-standard defaults set. The
default
> character set for USENET communications, if no other is mentioned in
> the headers of a message, is supposed to be ISO latin-1.)

The use of non-standard characters (defined informally as things most
programmers don't see on their keyboard) has severely limited the use
of APL. I would be very wary of adding a similar feature to Good Old
Fortran. Already there have been such reckless innovations as lower
case letters and the use of symbols such as ">". I think your need to
explain why your message may not be displayed correctly on some
computers argues against the proposed new syntax.

James Giles

2005-01-26, 3:59 am

beliavsky@aol.com wrote:
....
>
> The use of non-standard characters (defined informally as things most
> programmers don't see on their keyboard) has severely limited the use
> of APL. I would be very wary of adding a similar feature to Good Old
> Fortran. Already there have been such reckless innovations as lower
> case letters and the use of symbols such as ">". I think your need to
> explain why your message may not be displayed correctly on some
> computers argues against the proposed new syntax.

Well, your definition of "reckless" would strike most people as
peculiar. I'd really hate to have to program in UPPER CASE ONLY.
Nor would I prefer the bad old days of doing without ">" and other
useful characters.

My explanation was an indirect way of pointing out that all people
having access to usenet already have the characters I was discussing.
As for "things most programmers don't see on their keyboard", it's
no longer the old days: keyboards can be reprogrammed and relabeled.
I have all those characters on my keyboard. And it's an off the shelf
generic PC keyboard.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Brooks Moses

2005-01-26, 3:59 am

James Giles wrote:
> beliavsky@aol.com wrote:
>
> Well, your definition of "reckless" would strike most people as
> peculiar. I'd really hate to have to program in UPPER CASE ONLY.
> Nor would I prefer the bad old days of doing without ">" and other
> useful characters.

I believe that was sarcasm. That said, I have seen a set of C #define
statements for allowing beginning C programmers to use such things as
..GT. and .LT. instead of the "difficult to read" < and >, and those were
meant seriously.

> My explanation was an indirect way of pointing out that all people
> having access to usenet already have the characters I was discussing.
> As for "things most programmers don't see on their keyboard", it's
> no longer the old days: keyboards can be reprogrammed and relabeled.

The phrase was "don't see on their keyboard", not "can't see on their
keyboard after a little work". Specially-designed keyboards can be
built and sold, too, so obviously the question is not one of "possible",
it's one of "will it be percieved as a large barrier by newcomers?".
This will be perceived as a large barrier by newcomers, in exactly the
same way that buying a special keyboard would be perceived as a barrier.

I, for one, certainly have no desire to reprogram and relabel my
keyboard on every computer I might want to edit a Fortran file on,
particualarly when these are characters that I might use once a w

at
most. Nor do I wish to remember which numbers to type while holding
down the ALT key in order to get them, either.

I also have no desire to see Fortran suddenly become the evil test case
that demonstrates how half of the programming IDEs in existence can't
properly deal with characters that aren't 7-bit ASCII.

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

beliavsky@aol.com

2005-01-26, 3:59 am

James Giles wrote:
> beliavsky@aol.com wrote:
> ...
may have[color=darkred]
default[color=darkred]
in[color=darkred]
most[color=darkred]
use[color=darkred]
Old[color=darkred]
to[color=darkred]
>
> Well, your definition of "reckless" would strike most people as
> peculiar. I'd really hate to have to program in UPPER CASE ONLY.
> Nor would I prefer the bad old days of doing without ">" and other
> useful characters.

Sorry, I left out the smiley by mistake. I fully agree with you on the
above points.

James Giles

2005-01-26, 3:59 am

Brooks Moses wrote:
....
> I, for one, certainly have no desire to reprogram and relabel my
> keyboard on every computer I might want to edit a Fortran file on,
> particualarly when these are characters that I might use once a w

at
> most. Nor do I wish to remember which numbers to type while holding
> down the ALT key in order to get them, either.

What numbers? Who knows numbers? However, I don't expect
the use of Latin-1 to even be unusual in the future. Being stuck in
the mud is not a valid approach to design.

Also, the issue is "what is most legible" not "what is easiest to type".
Even on programs I use only once or twice, I typically read a code
several times more often than I write it.

> I also have no desire to see Fortran suddenly become the evil test case
> that demonstrates how half of the programming IDEs in existence can't
> properly deal with characters that aren't 7-bit ASCII.

I have no such desire either. One the other hand I hardly ever use IDEs.
The availability of Latin-1 is universal nowdays. By the time Fortran
even *could* include it in the standard, it will probably still be behind
the curve, with others already embracing UNICODE.

Finally, you both seem to have ignored the word "if" in my original
suggestion.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

James Giles

2005-01-26, 3:59 am

Ron Shepard wrote:
> In article <20050125114043.77dd9ac8.d.a.ham@citg.tudelft.nl>,
> David Ham <d.a.ham@citg.tudelft.nl> wrote:
>
>
> Another option that might be useful would be the ability to define
> operators that have no precedence. Such operators would require
> explicit parentheses to define the order of operations. If the
> parentheses aren't there, then a compile-time error would tell the
> programmer what needed to be corrected.

I've looked at this and thought of it and tried examples and rewrote
code with this in mind etc. I'm not sure that you're not right. In fact,
if there were a way to make this behavior the default one for defined
operators, I'm pretty sure that you are right. But, if it's only an optional
thing that programmers can use or not, I'm not sure the two kinds of
behavior might make things worse. It's hard to tell without actually
instrumenting a compiler with the feature and giving it an extended
trial (with lots more users than just myself).

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

glen herrmannsfeldt

2005-01-26, 3:59 am

James Giles wrote:

[color=darkred]
> What numbers? Who knows numbers? However, I don't expect
> the use of Latin-1 to even be unusual in the future. Being stuck in
> the mud is not a valid approach to design.

> Also, the issue is "what is most legible" not "what is easiest to type".
> Even on programs I use only once or twice, I typically read a code
> several times more often than I write it.

PL/I and C both include ways to encode the less common characters
using a smaller character set. Java uses unicode as its native
character set, and supplies escapes to represent unicode using
ASCII characters, but does assume ASCII is available. Java
even allows all unicode letters in identifiers, even some that
look exactly like ASCII letters.

If you want to add new characters, supplying unicode escapes
might not be a bad way to go.

-- glen

Jan Vorbrüggen

2005-01-26, 8:57 am

> I've looked at this and thought of it and tried examples and rewrote
> code with this in mind etc. I'm not sure that you're not right. In fact,
> if there were a way to make this behavior the default one for defined
> operators, I'm pretty sure that you are right.

I would agree. My experience is with occam2 that has _no_ precedence
defined at all - and all type conversions must be made explicitly. Now,
that's probably going just a little overboard - but only a teeny weeny
little bit.

If it were to be optional - and at this point in time, given the desire
to have backwards compatibility there is no choice but to make it so -
the declaration of no-precedence should be in the hands of the code that
defines the operator, not in the hands of the code that uses it. That
seems like a useful modification to me.

Jan

David Ham

2005-01-26, 8:57 am

On Wed, 26 Jan 2005 10:38:02 +0100
Jan Vorbr=FCggen <jvorbrueggen-not@mediasec.de> wrote:

>=20
> I would agree. My experience is with occam2 that has _no_ precedence
> defined at all - and all type conversions must be made explicitly.
> Now, that's probably going just a little overboard - but only a teeny
> weeny little bit.
>=20
> If it were to be optional - and at this point in time, given the
> desire to have backwards compatibility there is no choice but to make
> it so - the declaration of no-precedence should be in the hands of the
> code that defines the operator, not in the hands of the code that uses
> it. That seems like a useful modification to me.
>=20
> Jan

Given that (for better or worse) Fortran has chosen to give defined
operators a precedence, perhaps it would be better if compilers were to
offer a switch which would warn (or error if you really want) whenever a
defined operator is used in a situation which relies on the precedence
rules. That way the programmer can get the feedback which no precedence
provides without mucking with decisions already made in Fortran.

David

Gordon Sande

2005-01-26, 3:58 pm

David Ham wrote:
> On Wed, 26 Jan 2005 10:38:02 +0100
> Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> wrote:
>
>
>
>
> Given that (for better or worse) Fortran has chosen to give defined
> operators a precedence, perhaps it would be better if compilers were to
> offer a switch which would warn (or error if you really want) whenever a
> defined operator is used in a situation which relies on the precedence
> rules. That way the programmer can get the feedback which no precedence
> provides without mucking with decisions already made in Fortran.
>
> David

How about warning for the case of

a / b * c

which means

( a / b ) * c

but could be written when

a / ( b * c )

was intended. It could be written as

a * c / b

except for various good reasons for not doing so.
One might either be following the mathematics or being
careful about scaling.

James Giles

2005-01-26, 8:58 pm

Gordon Sande wrote:
....
> How about warning for the case of
>
> a / b * c
>
> which means
>
> ( a / b ) * c
>
> but could be written when
>
> a / ( b * c )
>
> was intended. It could be written as
>
> a * c / b
>
> except for various good reasons for not doing so.
> One might either be following the mathematics or being
> careful about scaling.

I've seen recommendations to make divide non-associative. That
is, when used with operators of the same precedence (including
itself) parenthesis must be used to express intended meaning.
I don't know that anything more than a warning, as you suggest here,
is really needed. But it *would* be a good thing to have the optional
warning. The same goes for:

-x ** n

The negation is applied after the exponentiation, in spite of the
probable intent (based on how whitespace is used) that it be
applied first. Again, an optional warning would be useful. Those
that always ignore such warnings, or don't even enable them do
so at their own peril.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Gordon Sande

2005-01-26, 8:58 pm

James Giles wrote:
> Gordon Sande wrote:
> ....
>
>
>
> I've seen recommendations to make divide non-associative. That
> is, when used with operators of the same precedence (including
> itself) parenthesis must be used to express intended meaning.
> I don't know that anything more than a warning, as you suggest here,
> is really needed. But it *would* be a good thing to have the optional
> warning. The same goes for:
>
> -x ** n
>
> The negation is applied after the exponentiation, in spite of the
> probable intent (based on how whitespace is used) that it be
> applied first. Again, an optional warning would be useful. Those
> that always ignore such warnings, or don't even enable them do
> so at their own peril.
>

Ahem!

Compiler writers seem to be happy to scold me for using equality
tests on floating point numbers but I am not aware of any that flag
either of these. Are there any vendors who have either warning?

I have much code that uses -1.0 as a marker for missing values
in data sets of non-negative numbers so I have a particular
dislike for the equality testing warning. Fortunately the worst
offenders have procedures for turning of particular warnings.

My impression has been that associative divide is either a
design error or laziness on the part of the parser designers.
In Fortran it is a bit late to fix the design error but that
is not a very good excuse for not issuing warnings.

James Giles

2005-01-27, 8:58 pm

For what it's worth, I just thought of another way to provide
the ability to define operators with a specified precedence.
The idea was always possible, but I always considered it
to cumbersome sytactically to recommend. But this variation
is maybe alright.

The idea is to allow operators to be defined that are composed
with an existing operator as part of the new one. So, you might
let someone define an operator */, or ++, with the rule that the new
operator would have the same precedence as the existing operator
matching the first character(s) of the new operator. That is, */
would have the same precedence as *, ++ the same precedence
as +, and *** the same precedence as **, etc.

Well, like I said, this is an old idea that's cumbersome because it
has too many limitations. You can't have an operator like <- or
>+ because that's ambiguous with present legal uses of those
characters as separate operators. So, you would have to have
special set of rules to decide which characters could follow
which others, and it's all a mess. In fact, operators like ++
or *- would be ambiguous with various implementations'
extensions.

But what about named operators? Those could be used with existing
operator characters within. For example, you could have .cross*.,
and have it mean that the CROSS operator has the same precedence
as the * operator. Since this is a purely syntactic property of the
operator itself, there would be no feedback required from the
semantics of the program in order to correctly parse expressions,
so the major difficulty with user defined precedence would be
eliminated.

flag = Anthony .*cross. Cleopatra == star_crossed_lovers !?

Now, in Fortran there are some precedences that could not be
selected this way. For example, you couldn't have an operator
with the same precedence as .and. since .myopand. already
has a meaning. So, it's maybe not likely to pass the committee.
But, it is another possibility.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Sponsored Links