Fortran - "<>", a relational operator?

Author

"<>", a relational operator?

Corkavenger@gmail.com

2005-05-03, 3:59 am

Hi,

I get the following error message when compiling some code (um, that I
did not write...):
********
Error: Syntax error, found '>' when expecting one of: ( <IDENTIFIER>
<CHAR_CON_KIND_PARAM> <CHAR_NAM_KIND_PARAM> <CHARACTER_CONSTANT>
<INTEGER_CONSTANT> ...
if (gSetFocus <> 0) then
********

The code referenced above is here:

********
! This code is used to move the input focus to an enabled button
! It calls Win32 APIs directly.
if (gSetFocus <> 0) then
hwnd = GetDlgItem(dlg % hwnd, gSetFocus)
hwnd = SetFocus(hwnd)
gSetFocus = 0
endif
********

I suspect that "<>" is a relational operator, such as "not equal to,"
but I've seen "/=" and ".ne." for that, and no reference to "<>"
anywhere I've looked. If you know what this means, do tell! I tried
replacing the "<>" with ".ne.", and the error no longrer appears. But
that might mean I've created other problems.

CA

Richard Maine

2005-05-03, 3:59 am

Corkavenger@gmail.com writes:

> if (gSetFocus <> 0) then
....
> I suspect that "<>" is a relational operator, such as "not equal to,"
> but I've seen "/=" and ".ne." for that, and no reference to "<>"
> anywhere I've looked. If you know what this means, do tell! I tried
> replacing the "<>" with ".ne.", and the error no longrer appears. But
> that might mean I've created other problems.

I suspect that you did the right thing. (Or substituting /= would have
been equivalent). I'd bet fairly good money that the person who did write
the code in question meant not equals and either

a. used a compiler that accepted <> as a nonstandard and nonportable
equivalent (that is the syntax used in some other languages), or

or

b. didn't actually run the code through a compiler at all. Given the
problem mentioned in your previous post, there is at least some
reason to suspect this, but that might be a little harsh. :-(

--
Richard Maine
email: my last name at domain
domain: summertriangle dot net

Walt Brainerd

2005-05-03, 3:59 am

Corkavenger@gmail.com wrote:

> Hi,
>
> I get the following error message when compiling some code (um, that I
> did not write...):
> ********
> Error: Syntax error, found '>' when expecting one of: ( <IDENTIFIER>
> <CHAR_CON_KIND_PARAM> <CHAR_NAM_KIND_PARAM> <CHARACTER_CONSTANT>
> <INTEGER_CONSTANT> ...
> if (gSetFocus <> 0) then
> ********
>
> The code referenced above is here:
>
> ********
> ! This code is used to move the input focus to an enabled button
> ! It calls Win32 APIs directly.
> if (gSetFocus <> 0) then
> hwnd = GetDlgItem(dlg % hwnd, gSetFocus)
> hwnd = SetFocus(hwnd)
> gSetFocus = 0
> endif
> ********
>
> I suspect that "<>" is a relational operator, such as "not equal to,"
> but I've seen "/=" and ".ne." for that, and no reference to "<>"
> anywhere I've looked. If you know what this means, do tell! I tried
> replacing the "<>" with ".ne.", and the error no longrer appears. But
> that might mean I've created other problems.
>
> CA
>
The comparison <> is legal in Pascal--check that famous
book "Pascal", by Goldberg, Brainerd, and Gross (1984)!

Anyway, you are right again: /= is the "new" way to do it
and .ne. is the old way. They are completely equivalent.

Let's hope the original author meant "not equal".

--
Walt Brainerd +1-877-355-6640 (voice & fax)
The Fortran Company +1-520-760-1397 (outside USA)
6025 N. Wilmot Road walt@fortran.com
Tucson, AZ 85750 USA http://www.fortran.com

James Van Buskirk

2005-05-03, 3:59 am

<Corkavenger@gmail.com> wrote in message
news:1115083866.124595.223160@f14g2000cwb.googlegroups.com...

> if (gSetFocus <> 0) then

CVF! They didn't even realize that they were accepting
this as an extension, but when they got rid of the
extension people starting complaining. It did mean .NE.
on that compiler.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

robert.corbett@sun.com

2005-05-03, 3:59 am

The operator "<>" was a feature of the Fortran 8X and 9X drafts.
It meant .NE..

Many vendors implement features from the drafts. If the features
change, it is usually easier to leave them in unless they are
incompatible with the subsequent standard.

Bob Corbett

Gordo

2005-05-03, 4:00 pm

Corkavenger@gmail.com wrote:
> I suspect that "<>" is a relational operator, such as "not equal to,"
> but I've seen "/=" and ".ne." for that, and no reference to "<>"
> anywhere I've looked. If you know what this means, do tell! I tried
> replacing the "<>" with ".ne.", and the error no longrer appears. But
> that might mean I've created other problems.

As others have pointed out, <> is an extension. The problem with extensions
is that programmers who use them have code that is hard to port. Remember
all the difficulties that some people had porting their VAX Fortran. For
me, the best feature of any vendor's Fortran language reference manual is
having the extensions printed in a different color.

Rich Townsend

2005-05-03, 4:00 pm

Gordo wrote:
> Corkavenger@gmail.com wrote:
>
>
>
> As others have pointed out, <> is an extension. The problem with extensions
> is that programmers who use them have code that is hard to port. Remember
> all the difficulties that some people had porting their VAX Fortran. For
> me, the best feature of any vendor's Fortran language reference manual is
> having the extensions printed in a different color.
>
>
>

Preferably, white.

gary.l.scott@lmco.com

2005-05-03, 4:00 pm

Corkaven...@gmail.com wrote:
> Hi,
>
> I get the following error message when compiling some code (um, that
I
> did not write...):
> ********
> Error: Syntax error, found '>' when expecting one of: ( <IDENTIFIER>
> <CHAR_CON_KIND_PARAM> <CHAR_NAM_KIND_PARAM> <CHARACTER_CONSTANT>
> <INTEGER_CONSTANT> ...
> if (gSetFocus <> 0) then
> ********
>
> The code referenced above is here:
>
> ********
> ! This code is used to move the input focus to an enabled button
> ! It calls Win32 APIs directly.
> if (gSetFocus <> 0) then
> hwnd = GetDlgItem(dlg % hwnd, gSetFocus)
> hwnd = SetFocus(hwnd)
> gSetFocus = 0
> endif
> ********
>
> I suspect that "<>" is a relational operator, such as "not equal to,"
> but I've seen "/=" and ".ne." for that, and no reference to "<>"
> anywhere I've looked. If you know what this means, do tell! I tried
> replacing the "<>" with ".ne.", and the error no longrer appears.
But
> that might mean I've created other problems.
>
> CA

I'm not sure I like this extension. It could mean either:
"less than .and. greater than" (physical impossibility I know)
-or-
"less than .or. greater than"

3270 keyboards have a "not" symbol. Too bad it isn't more commonplace.
I'm also not sure I like "/=" as my first thought is that it is an
escape sequence or means "literally "="" rather than "not equal".
Specifying something as "literal" is often used for macro substitution
purposes in some languages.

Walt Brainerd

2005-05-03, 8:57 pm

gary.l.scott@lmco.com wrote:
> Corkaven...@gmail.com wrote:
>
>
> I
>
>
> But
>
>
>
> I'm not sure I like this extension. It could mean either:
> "less than .and. greater than" (physical impossibility I know)
> -or-
> "less than .or. greater than"
>
> 3270 keyboards have a "not" symbol. Too bad it isn't more commonplace.
> I'm also not sure I like "/=" as my first thought is that it is an
> escape sequence or means "literally "="" rather than "not equal".
> Specifying something as "literal" is often used for macro substitution
> purposes in some languages.
>
/= is "correct" because just as <= stands for the two
characters superimposed, so does /= stand for the way "not
equals" is usually written as the two characters superimposed.

I usually think of \ as the escape character, but maybe
messing with Unix and trying to avoid DOS for many years
has polluted my brain.

What does cause problems (for those who program in something
other than Fortran) is that other languages mostly use something
different. (But != doesn't work well in Fortran. :-)

--
Walt Brainerd +1-877-355-6640 (voice & fax)
The Fortran Company +1-520-760-1397 (outside USA)
6025 N. Wilmot Road walt@fortran.com
Tucson, AZ 85750 USA http://www.fortran.com

glen herrmannsfeldt

2005-05-03, 8:57 pm

Walt Brainerd wrote:

(snip)

> /= is "correct" because just as <= stands for the two
> characters superimposed, so does /= stand for the way "not
> equals" is usually written as the two characters superimposed.

Note that /= is the C divide assignment operator.

i /= 3; is equivalent to i=i/3; If you are used to C, the
Fortran operator looks very strange.

-- glen

James Giles

2005-05-03, 8:57 pm

gary.l.scott@lmco.com wrote:
....
> I'm not sure I like this extension. It could mean either:
> "less than .and. greater than" (physical impossibility I know)
> -or-
> "less than .or. greater than"

In floating point, the meaning "less than or greater than"
is different from "not equal to" anyway. There are four
order relations in floating point, less than , equal, greater
than, and unordered. "Less than or greater than" ought to
return true for two of those possibilities and false for the
other two, while "not equal" should return true for three
of the possibilities and false only when the operands are
equal.

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

[JvO]

2005-05-04, 8:57 am

Richard Maine schreef:
> Corkavenger@gmail.com writes:
>
> ...
to,"[color=darkred]
tried[color=darkred]
But[color=darkred]
>
> I suspect that you did the right thing. (Or substituting /= would
have
> been equivalent). I'd bet fairly good money that the person who did
write
> the code in question meant not equals and either
>
> a. used a compiler that accepted <> as a nonstandard and nonportable
> equivalent (that is the syntax used in some other languages), or

In fact, <> was in the early drafts of Fortran 8x instead of /=
And [ ] instead of (/ /)
Mine is called version 103 of February 1987 ...

BTW, this draft contains an Appendix F called "Removed extensions" with
lots of useful things that might be incorporated in the next revision.
Example: BIT type, I would like to have that back.

[JvO]

> or
>
> b. didn't actually run the code through a compiler at all. Given the
> problem mentioned in your previous post, there is at least some
> reason to suspect this, but that might be a little harsh. :-(
>
> --
> Richard Maine
> email: my last name at domain
> domain: summertriangle dot net

[JvO]

2005-05-04, 8:57 am

epc8@juno.com

2005-05-04, 3:58 pm

Walt Brainerd wrote:

> The comparison <> is legal in Pascal--check that famous
> book "Pascal", by Goldberg, Brainerd, and Gross (1984)!
>
> Anyway, you are right again: /= is the "new" way to do it
> and .ne. is the old way. They are completely equivalent.

Pascal also had some substitutes for those of us whose keyboards did
not have special characters:

(* *) for { }
(. .) for [ ]

(back in ye olde days when ^ displayed as up arrow)

epc8@juno.com

2005-05-04, 3:58 pm

as does the mod operator % used in structure members instead of .

Gary L. Scott

2005-05-04, 3:58 pm

Walt Brainerd wrote:
> gary.l.scott@lmco.com wrote:
>
> /= is "correct" because just as <= stands for the two
> characters superimposed, so does /= stand for the way "not
> equals" is usually written as the two characters superimposed.

Yes, was just an issue with the "/" character. It also looks like a
"divide =". But given no "not" symbol on most keyboards, it's probably
as good as any.

>
> I usually think of \ as the escape character, but maybe
> messing with Unix and trying to avoid DOS for many years
> has polluted my brain.
>
> What does cause problems (for those who program in something
> other than Fortran) is that other languages mostly use something
> different. (But != doesn't work well in Fortran. :-)
>

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Richard E Maine

2005-05-04, 3:58 pm

In article <1115208171.931268.321310@z14g2000cwz.googlegroups.com>,
"epc8@juno.com" <epc8@juno.com> wrote:
[this was the entire post]

> as does the mod operator % used in structure members instead of .

Just a note intended to be helpful. Realize that many people will end up
reading postings in a different order than you see them, or in order,
but spread out over time. Anyway, for whatever reason, they might not
see what post you are replying to without going to extra trouble. Thus
replies often need at least a little context in order to be
understandable. Sometimes a reply is self-contained enough to stand
alone, but the isolated line above does not.

I'm not advocating the practice of quoting hundreds of lines to add a
one-line comment at the end. Heck, I sometimes don't even get past the
quotes to see the added line in those. I'm just suggesting enough
quoting to establish context, or perhaps describing the context if that
works better than a quote.

The general message (applicable to far more than just usenet postings)
is to consider the context in which the reader will read what you write;
it may be different from the context in which you are writing it.

I'm not disagreeing with your point - just saying that you made it a bit
of work to figure out what your point was. I think I did get it, but I
suspect that some other readers just said "huh?" and then passed it by.

This is intended as a helpful hint rather than as a flame.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

epc8@juno.com

2005-05-04, 3:58 pm

[reference to differences in idioms between C and Fortran notation]

Richard E Maine wrote:
> In article <1115208171.931268.321310@z14g2000cwz.googlegroups.com>,
> "epc8@juno.com" <epc8@juno.com> wrote:
> [this was the entire post]
>
>
> Just a note intended to be helpful. Realize that many people will end
up
> reading postings in a different order than you see them, or in order,

> but spread out over time.

[snip]

> This is intended as a helpful hint rather than as a flame.
>
> --
> Richard Maine | Good judgment comes from
experience;

Sorry about that. I pushed the POST button in haste. Sometimes when I
post through Google Groups, I lose the ability to quote part of a
previous message or to edit my submission. Usually this happens when I
have not deleted my cookies recently. Thanks for the advice.

Richard E Maine

2005-05-04, 8:58 pm

In article <1115230816.755073.325140@f14g2000cwb.googlegroups.com>,
"epc8@juno.com" <epc8@juno.com> wrote:

> Richard E Maine wrote:
[advice about posting style]

> Sorry about that. I pushed the POST button in haste....

I suppose I should have figured that out, as it wasn't your usual style.
Oh well.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

James Giles

2005-05-04, 8:58 pm

glen herrmannsfeldt wrote:
....
> Note that /= is the C divide assignment operator.
>
> i /= 3; is equivalent to i=i/3; If you are used to C, the
> Fortran operator looks very strange.

Well, a reference to C in a discussion of clear syntax is a
little problematical. Note that /* is the C comment marker.
Note that /* is an infix divide operator followed by a prefix
dereferencing operator in C. So, in C, what is:

*a++ = *b++ /*c++

--
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-05-04, 8:58 pm

James Giles wrote:

(snip about /= operator)

> Well, a reference to C in a discussion of clear syntax is a
> little problematical. Note that /* is the C comment marker.
> Note that /* is an infix divide operator followed by a prefix
> dereferencing operator in C. So, in C, what is:

> *a++ = *b++ /*c++

A popular rule for tokenizing is to take the longest
token that is a legal token. (Not considering that it might
not be legal at that position.)

You could also find ambiguous the -- operator and successive
uses of the - operator. i=---j; for example.

For the compiler I tried it on,

x=---sqrt(x);

was valid, so it seems that it does recognize it as three
unary -, and not a decrement operator.

It seems that early forms of C had =- and =+ operators
instead of the current -= and +=, and some compilers allowed
them much later than they should have.

I believe comments need to be recognized by the preprocessor,
which can't really do a full syntax analysis on it input,
as the output could be different.

#define lpar (

a=sqrt lpar x ); is legal.

I believe, though, that

#define comment /*

will result in an unclosed comment, and not define a new comment
operator. You can comment out preprocessor commands.

-- glen

(comp.lang.c added)

NuclearWizard

2005-05-06, 3:59 pm

HAHAHAHAHAHAHA.

Brooks Moses

2005-05-10, 3:59 am

"Gary L. Scott" wrote:
> Walt Brainerd wrote:
>
> Yes, was just an issue with the "/" character. It also looks like a
> "divide =". But given no "not" symbol on most keyboards, it's probably
> as good as any.

Particularly given that "!=", which would be logical (at least for me),
is a rather bad idea what with "!" usually introducing comments.

Personally, I tend to find it easier to stick with ".ne." than to try to
remember "/=".

- Brooks

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

Paul Van Delst

2005-05-10, 3:59 pm

Brooks Moses wrote:
> "Gary L. Scott" wrote:
>
>
>
> Particularly given that "!=", which would be logical (at least for me),
> is a rather bad idea what with "!" usually introducing comments.
>
> Personally, I tend to find it easier to stick with ".ne." than to try to
> remember "/=".

Hello,

I guess it depends on where one initially grounds their "perception anchor". I like the
"/=" because it most closely approximates the way I would write the not equal symbol on
paper. I'm also comfortable with the "!=" (outside of Fortran of course) since I've used
that for years in shell script string comparisons. And people can still use .ne. in
Fortran source code if they prefer that - one gets the cake and can scarf it down. :o)

It's just like the structure component separator character debate. Which is "better": "."
or "%"? Same dog different leg AFAIC. At the end of the day the job still gets done.

cheers,

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

Arjen Markus

2005-05-10, 3:59 pm

Paul Van Delst wrote:
>

>
> It's just like the structure component separator character debate. Which is "better": "."
> or "%"? Same dog different leg AFAIC. At the end of the day the job still gets done.
>

I keep wondering when programming in C, why there is a "." and a "->"
separator?
I know: the compiler will complain if I use the wrong one, but that is
exactly my
point: the compiler ***knows*** which one I should have used, so why are
there
two?

There is another subject for nasty and bloody battles: _ versus
capitalisation ;)
Oh and of course the use of 2, 3 or 4 spaces, or tabs .... All quite
pointless
IMHO as there is no rational argument for any particular choice.

Regards,

Arjen

Paul Van Delst

2005-05-10, 3:59 pm

Arjen Markus wrote:
> Paul Van Delst wrote:
>
>
>
>
> I keep wondering when programming in C, why there is a "." and a "->"
> separator?
> I know: the compiler will complain if I use the wrong one, but that is
> exactly my
> point: the compiler ***knows*** which one I should have used, so why are
> there
> two?

Huh. My lone C book tells me that
pointer_to_structure -> member_name
is equivalent to
(*pointer_to_structure).member_name
Weird. <sarcasm>Maybe the -> was introduced to save all those darn, useless keystrokes?
Sort of like how
++i
is the same as
i = i + 1
Or is it
i++?
</sarcasm>

:o)

>
> There is another subject for nasty and bloody battles: _ versus
> capitalisation ;)

I've read a bit of stuff about all that. I've used both separately and now I notice that I
use both together (not by design, it just seemed to happen). E.g. a variable name like
Other_YmaxDiff is not unusual. Sometimes I might even do Other_yMaxDiff just to mix it up
a bit. :o)

> Oh and of course the use of 2, 3 or 4 spaces, or tabs .... All quite
> pointless
> IMHO as there is no rational argument for any particular choice.

Well, tabs are not legal Fortran characters (dunno if I used the correct terminology
there, but you know what I mean) so that choice is easy (I send code back to people, or
tell them not to use tabs anymore). As for 2, 3, or 4 spaces -- whatever floats peoples
boats is fine by me. As long as the code is readable.

One thing that I find quite weird is when I read some computer language instruction books
(in particular C/C++, but I'm sure others have it) and the advice is given to have minimal
comments because the intent of the code should be self evident, i.e. if you need comments
to describe what the code is doing, then the code itself is no good. I have *never* seen
code (in any language, although I obviously have a bias against languages I'm unfamiliar
with) that couldn't stand to have a bit more commenting to make the intent clearer.
Bizarre. Then again, maybe that particular type of advice no longer has the cache it had.

Anyway...

cheers,

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

Richard E Maine

2005-05-10, 3:59 pm

In article <d5qgrq$f9a$1@news.nems.noaa.gov>,
Paul Van Delst <paul.vandelst@noaa.gov> wrote:

> I have *never* seen code ... that couldn't stand to have a bit
> more commenting to make the intent clearer.

Indeed. Though I'll note that when I transitioned from f77 to f90,
several of my comments essentially turned into compilable code with only
minor syntactic changes. Not all of them by any means, but in
particular...

My f77 code used to have comments documenting whether each dummy
argument was for input, output, or both. These comments turned into
INTENT attributes in my f90 code.

And I used to like to use comments to identify the ends of large DO
loops and IF blocks. I picked that practice up from when I did some work
in Pascal (where comparable use of comments is widespread because
otherwise it is darn near impossible to keep track of what an "end" is
ending). Those comments turned into compilable construct labels in f90.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Richard Edgar

2005-05-10, 3:59 pm

Paul Van Delst wrote:

>
>
> Huh. My lone C book tells me that
> pointer_to_structure -> member_name
> is equivalent to
> (*pointer_to_structure).member_name
> Weird.

Indeed. I suspect that part of the answer lies in the fact that C's
pointers are just integers, so some extra visual 'aid' might be useful
to remind people what's a pointer, and what's a 'real' structure.

Of course, I know well the feeling (going back to my BASIC days) of
"Well, if you _know_ that there's a missing ")" why don't you just put
it in yourself?"

:-)

> <sarcasm>Maybe the -> was introduced to save all those darn,
> useless keystrokes? Sort of like how
> ++i
> is the same as
> i = i + 1
> Or is it
> i++?
> </sarcasm>

ISTR being told by someone who'd written a C compiler that the standard
was rather vague on the meaning of

i = i++ * ++i;

which has rather different results depending on when i gets incremented...

Richard

glen herrmannsfeldt

2005-05-10, 3:59 pm

Paul Van Delst wrote:
(snip)

[color=darkred]
> Huh. My lone C book tells me that
> pointer_to_structure -> member_name
> is equivalent to
> (*pointer_to_structure).member_name

With Fortran pointers the pointed to value is used in many cases
without any special operator just using the pointer name.
(I will try not to confuse it any more here.)

In C you pretty much always tell the compiler when you are using a
pointer and when you are using what the pointer points to.

The unary * operator, and binary [] operator dereference a pointer,
the latter with a supplied offset.

As far as what the compiler knows, consider that the [] operator in
C is commutative. That is, A[I] is exactly the same as I[A].
The compiler knows which one is a pointer and which is an offset.
Specifically, A[I] is the same as *(A+I) and *(I+A), and so I[A].

Since many operations can be applied to either a pointer or what it
points to it is often important to get it right.

*i++ dereferences the pointer, gives you the value, and then increments
the pointer, as *(i++) would do. (*i)++ increments the value pointed to.

I have seen multiple levels of structure pointer dereferencing:

one -> two -> three -> four=0; is more readable than

*(*(*(one).two).three).four=0; The ()'s are required.

-- glen

glen herrmannsfeldt

2005-05-10, 3:59 pm

Richard E Maine wrote:
(snip)

> And I used to like to use comments to identify the ends of large DO
> loops and IF blocks. I picked that practice up from when I did some work
> in Pascal (where comparable use of comments is widespread because
> otherwise it is darn near impossible to keep track of what an "end" is
> ending). Those comments turned into compilable construct labels in f90.

How many compilers enforce the match between the DO label and the
END DO label?

How about between the SUBROUTINE name and the END SUBROUTINE name?

There was one program posted where the END SUBROUTINE name was
different, though I don't know that it actually compiled that way.

-- glen

glen herrmannsfeldt

2005-05-10, 3:59 pm

Richard Edgar wrote:

(snip regarding what a compiler knows about pointers)

> Of course, I know well the feeling (going back to my BASIC days) of
> "Well, if you _know_ that there's a missing ")" why don't you just put
> it in yourself?"

With many compilers one error in a statement causes it to be ignored.

Consider a DIMENSION statement with ten arrays missing the final ).
Why can't the compiler at least consider the first nine arrays dimensioned?

The first PL/I compiler I knew was pretty good about fixing up
statements so it could continue compiling, probably including missing
")", and definitely including missing ";".

In the batch processing days when you might only get one compiler run
a day it could make a big difference.

-- glen

Richard E Maine

2005-05-10, 3:59 pm

In article <ENWdnZ-QSdJZbx3fRVn-tQ@comcast.com>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> How many compilers enforce the match between the DO label and the
> END DO label?
>
> How about between the SUBROUTINE name and the END SUBROUTINE name?

Every compiler that conforms to the standard. Those requirements are
constraints, which are among the things that compilers are required to
be able to diagnose.

Generally speaking, things that are as trivially compile-time-checkable
as this tend to be constraints.

And while compilers often have options to turn off some error messages
(and the default is sometimes even to be silent), I have a hard time
imagining anyone bothering with such an option for this case; nor have I
ever heard of one.

If you do find a compiler that fails to diagnose this, I suggest
submitting a bug report on the violation of the standard.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Paul Van Delst

2005-05-10, 3:59 pm

glen herrmannsfeldt wrote:
>
> I have seen multiple levels of structure pointer dereferencing:
>
> one -> two -> three -> four=0; is more readable than
>
> *(*(*(one).two).three).four=0;

You think so? For readability and intent, I prefer the second form. I can immediately tell
what's going on. The first form somewhat obfuscates the underlying structure (IMO).

Of course, I would argue that the whole construct/data structure is ill-designed to begin
with to require that sort of nesting, but I am a simple man. :o)

cheers,

paulv

p.s. I have used constructs nearly exactly like your example in some of my IDL code. After
a w

, I forget what I was trying to do.

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

James Giles

2005-05-10, 8:58 pm

Paul Van Delst wrote:
....
> One thing that I find quite weird is when I read some computer
> language instruction books (in particular C/C++, but I'm sure [...]

I guess that's the first time I've heard of C/C++ programmers being
interested in code legibility at all. :-)

> [...] others have it) and the advice is given to have minimal comments
> because the intent of the code should be self evident, i.e. if you
> need comments to describe what the code is doing, then the code
> itself is no good. I have *never* seen code (in any language,
> although I obviously have a bias against languages I'm unfamiliar
> with) that couldn't stand to have a bit more commenting to make the
> intent clearer. Bizarre. Then again, maybe that particular type of
> advice no longer has the cache it had.

Well, I've seen code that could be made more legible with *different*
comments than it had. But often that would have been *fewer*
comments. I've seen programs where the comments outnumbered
the code by four or five to one, and I couldn't decipher what the
program did until I deleted all comments! The novel the guy was
writing didn't elucidate anything.

It *is* true thart if the reader can be expected to understand the
algorithm being implemented and can be expected to understand
the language being used, then the comments should be to aid
navagation (Rich Maine mentions labeling blocks in this conection)
and to jog memory on tricky parts of the algorithm. The best place
to actually teach the algorithm or the language is somewhere other
than in the middle of a program.

--
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-05-10, 8:58 pm

Richard Edgar wrote:
.....
> ISTR being told by someone who'd written a C compiler that the
> standard was rather vague on the meaning of
>
> i = i++ * ++i;
>
> which has rather different results depending on when i gets
> incremented...

Well, that statement violates the C standard, but in a way that
implementations are not required to detect or report:

Between the previous and next sequence point an object
shall have its stored value modified at most once by the
evaluation of an expression. Furthermore, the prior value
shall be accessed only to determine the value to be stored.

In this case, the sequence points are the previous semicolon and
the semicolon shown.

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

Richard E Maine

2005-05-10, 8:58 pm

In article <d5qt6j$p6u$1@news.nems.noaa.gov>,
Paul Van Delst <paul.vandelst@noaa.gov> wrote:

> glen herrmannsfeldt wrote:
>
> You think so? For readability and intent, I prefer the second form. I can
> immediately tell what's going on.

Different stroke...

I have trouble seeing what the second form is doing even after I'm told
that it does the same thing as the first. I think I'll have to take your
word for it. :-(

I think the parens nesting is the worst part. Your eye really
"immediately" sees where each one of those parens ends and thus what the
* before the parens operates on? I guess it is a sign of my eyesight
degrading with age, but my eye needs quite a bit of help with it.

The structure of the expression is such that the leftmost operators
operate on the rightmost operands. That's why all the parens are needed
and why my eye has trouble with it - hard to simultaneously focus on
that "*" at the very left operating on the "three" most of the way to
the right (I first wrote "four" instead of "three", illustrating my
difficulty in reading the darned thing.)

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Gordon Sande

2005-05-10, 8:58 pm

Richard E Maine wrote:
> In article <d5qt6j$p6u$1@news.nems.noaa.gov>,
> Paul Van Delst <paul.vandelst@noaa.gov> wrote:
>
>
>
>
> Different stroke...
>
> I have trouble seeing what the second form is doing even after I'm told
> that it does the same thing as the first. I think I'll have to take your
> word for it. :-(
>
> I think the parens nesting is the worst part. Your eye really
> "immediately" sees where each one of those parens ends and thus what the
> * before the parens operates on? I guess it is a sign of my eyesight
> degrading with age, but my eye needs quite a bit of help with it.
>
> The structure of the expression is such that the leftmost operators
> operate on the rightmost operands. That's why all the parens are needed

At the risk of being politically incorrect I will guess that you do
not speak German. I am told it is a "left parse" language rather
than a "right parse" language so that you only get to find out what
verb applies to the first noun at the end of the sentence, which
can be rather far away it the topic is at all interesting or
complicated. Maybe I have the slant of the parse trees reversed
and I seem to recall that the compound nouns of German have something
to do with how memory handles the parse order. Having displayed
my ignorance I expect the most sensible thing is to not post this.

Clearly it depends on one's training (that may even have to start
at an early age).

> and why my eye has trouble with it - hard to simultaneously focus on
> that "*" at the very left operating on the "three" most of the way to
> the right (I first wrote "four" instead of "three", illustrating my
> difficulty in reading the darned thing.)
>

Paul Van Delst

2005-05-10, 8:58 pm

Richard E Maine wrote:
> In article <d5qt6j$p6u$1@news.nems.noaa.gov>,
> Paul Van Delst <paul.vandelst@noaa.gov> wrote:
>
>
>
>
> Different stroke...
>
> I have trouble seeing what the second form is doing even after I'm told
> that it does the same thing as the first. I think I'll have to take your
> word for it. :-(
>
> I think the parens nesting is the worst part. Your eye really
> "immediately" sees where each one of those parens ends and thus what the
> * before the parens operates on? I guess it is a sign of my eyesight
> degrading with age, but my eye needs quite a bit of help with it.
>
> The structure of the expression is such that the leftmost operators
> operate on the rightmost operands. That's why all the parens are needed
> and why my eye has trouble with it - hard to simultaneously focus on
> that "*" at the very left operating on the "three" most of the way to
> the right (I first wrote "four" instead of "three", illustrating my
> difficulty in reading the darned thing.)

Well, I didn't say it was pretty! :o) And, I admit, for that sort of construct an editor
that automatically matches parentheses is a must (I need that anyway for much more mundane
expressions).

I was referring more to my "at a glance" response, rather than the "is the syntax
correct?" response. I think a lot of my preference is driven by the fact that the "->"
operator in the example is completely new to me in that context. The only other time I've
come across "->" is in IDL where it is a method invocation operator, e.g.
Object -> Class::Method
or
Result = Object -> Class::Method()
type of thing.

cheers,

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

Richard E Maine

2005-05-10, 8:58 pm

In article <bW8ge.35935$0X6.11229@edtnps90>,
Gordon Sande <g.sande@worldnet.att.net> wrote:

> At the risk of being politically incorrect I will guess that you do
> not speak German.

I took 2 semesters of it in undergrad school, but it never "stuck" well
enough for me to say that I can speak it (and indeed, barely well enough
to pass the second semester, though that might have had something to do
with my disinclination towards doing homework in undergrad school - I
could get by with that in technical courses).

I'll refrain from torturing the newsgroup with my attempts at Vogon
poetry. Or German either. :-)

Last time I tried my high school French here, it managed to come out
with an unintentional obscene implication, though I suppose some might
argue that this is natural for French. :-)

I'm afraid that I have long regretted that I didn't get exposure to
other languages when I was young enough to learn them more naturally; we
tend to be pretty bad about that in the US. High school is *WAY* too
late; we humans are pre-programmed to learn languages at a much younger
age.

Not that I've had much luck in teaching Fortran to my kids at age 2 or
so. :-)

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

John Harper

2005-05-10, 8:58 pm

In article <428047D5.29965DDC@cits1.stanford.edu>,
Brooks Moses <bmoses-nospam@cits1.stanford.edu> wrote:[color=darkred]
>"Gary L. Scott" wrote:

I write it on paper as | (i.e. achar(124)) superimposed on = so I feel
it's a pity that | was not included in the f95 character set. As it is
in the f2003 character set, may I suggest that the next version of
Fortran should allow |= as an alternative to /= for the benefit of
those who don't like /= and want something nearer ordinary mathematical
notation than .NE.

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

Dave Thompson

2005-05-16, 3:58 am

On Tue, 10 May 2005 17:15:51 +0200, Richard Edgar <rge21@astro.su.se>
wrote:

> Paul Van Delst wrote:
>
>
> Indeed. I suspect that part of the answer lies in the fact that C's
> pointers are just integers, so some extra visual 'aid' might be useful
> to remind people what's a pointer, and what's a 'real' structure.
>
No they aren't. They are just addresses -- or at least aren't required
to be more than just an address; an implementation is _permitted_ to
keep additional bounds/etc. information but not required, there isn't
much support for optimizing it, and users don't expect or demand it,
so sensible implementors don't. But they are distinct from integers,
and in particular have strides -- fixed ones, except for C99 VLA
types. And in Standard (portable) C there are significant restrictions
on comparing and computing them. OTOH in BCPL and B pointers were
truly just (computable) integers, and memory uniformly word-oriented.

I believe it had more to do with C's philosophy of "you only get what
you see". Remember C was designed as a System Implementation Language
(for Unix), not a general application language, where the philosophy
is more often "that's what I want; do whatever it takes". You only get
a dereference when you ask for it -- and with pass-by-value arguments,
you only get aliasing and/or change-to-outside when you ask. C also
has no whole array operations; if you want something done to all (or
many) elements of an array, you must do it yourself -- although for
array of char (character strings) (and now wide-char) in particular
there are standard library routines -- not core syntax -- for some
common operations. Originally it didn't have struct assignment (or
pass or return) although those were added. It is probably some kind of
tribute to the human spirit that C has been used so extensively for
applications without more failures than have in fact occurred.

> Of course, I know well the feeling (going back to my BASIC days) of
> "Well, if you _know_ that there's a missing ")" why don't you just put
> it in yourself?"
>
> :-)
>
As glen says there was more effort put into this in batch days. My
favorite was one time I fed an empty deck to PL/C -- or rather I
submitted an empty deck to someone who gave it to someone else who
submitted the job, after which someone else burst the printouts and
gave them to someone else who filed them where I could get them -- and
it constructed a complete and nearly "valid" (though useless) program
effectively out of thin air. DWIM indeed!

>
The side effect is the same as either; the result of i = i+1 is the
value after modification which is the same as ++i but not i++. This
(obviously) matters only if the result is used. (In C++ if i is of a
class type there is the further difference that prefix conventionally
returns a reference that doesn't require copying and allows further
operations, while postfix returns a value that does and may not.)

> ISTR being told by someone who'd written a C compiler that the standard
> was rather vague on the meaning of
>
> i = i++ * ++i;
>
> which has rather different results depending on when i gets incremented...
>
As James says, the Standard isn't vague at all -- this is specifically
undefined. (Unlike some other cases that are undefined by omission,
and thus sometimes harder to identify.) It isn't even required to
produce _any_ result. Like some other cases of Undefined Behavior this
was intended to allow for different implementations that (AFAIK all)
do produce _some_ result, but for more or less good reasons different
and possibly even invalid ones. Plus the principle that if you want a
given order, you should (and easily can) code it explicitly.

- David.Thompson1 at worldnet.att.net

Sponsored Links