Case-sensitivity in the Fortran compiler

[blicks]

Hello, fellow members!

Im totally new to this. I have just installed Intel Visual Fortran Composer XE 2011 and started to play around with the samples.

Im just wondering if there is any way to make the Intel Visual Fortran Composer XE 2011 case-sensitive? I have a colleague that says that you could enable case-sensitivity in the 9.1 version. Is this correct?

That is:
integer, parameter :: ROW=101

and

integer, parameter :: Row=101

would be two different variables.

Best regards and thanks in advance!

[anthonyrichards]

That way lies madness!

[blicks]

:)

Yes, I completely agree with you on that one.

But I have clients/colleague that are very persistent when it comes to this issue. They want the compiler to be case sensitive (this due to some name conversion standard).

So, is there any way to toggle the case sensitivity on/off in the Intel Fortran Compiler?

Thanks!

[mecej4]

The treatment of external names (routine names, common block names) can be controlled using the /names:{lowercase, uppercase, as_is} option.

Forcing case-sensitivity on variable names would, as far as Fortran is concerned, be the equivalent of driving drunk, seat-belt off and eyes closed. This feature is not supported by most compilers, so if you find a compiler that does support this property, you will be stuck with that compiler. Your source code would be useless to anyone else who prefers to use a different compiler. Worse, if you gave the sources to them, they would probably not suspect that the results will be junk.

[Arjen_Markus]

It may be possible via the option /names:as_is.

But the road is indeed one leading to madness - because it is contrary to Fortran's tradition and people
will be put on the wrong foot.

Regards,

Arjen

[rase]

And it's not only tradition, but also Fortran standard to make no difference between upper and lower case of variable names, if I remember correctly. Maybe Steve could provide a comment on the standard issue.

[IanH]

Do they actually want the compiler to be case sensitive or do they want the case of names in the source code to follow some convention? They are very different things. The first is silly, the second eminently reasonable.

The language is not case sensitive outside of character literals. Even if the language was case sensitive, actually relying on that (alone) to disambiguate names would be silly.

Where names from different modules clash you can use the rename clause part of the USE statement to rename one (or both) of the names to avoid problems. In terms of external names, C interoperability allows some things to have their binding name specified and this is case sensitive - BIND(C, NAME='XxYy').

Note that the example declarations in the original post are for constants, not variables.

[anthonyrichards]

Of course, we all know that C and C++ languages use case sensitivity, so I guess we are talking about users of those languages wanting Fortran to become so? Also, those of us who also use MathCad are also aware that VariableX is different from variablex.

However, just because a contageon is loose in one area, doesn't mean that we healthy types have to be exposed to it and catch it...and Doctor Fortran is on call for us, fortunately.

[jimdempseyatthecove]

If you use the Fortran PreProcessor (FPP) you can

#define Row RowLowCase

But then row, rOw, RoW and roW would all map to ROW

Jim Dempsey

[Steven_L_Intel1]

The Fortran language is case-insensitive. Code that requires otherwise is not Fortran, is non-portable and can lead to odd problems (such as intrinsics being required to be spelled in upper case).

As others have mentioned, there is a /names:as_is option that will make all identifiers case-sensitive, including local variables, but I very strongly recommend against using it.

If you are calling library routines with case-sensitive ways, there are much better ways of dealing with that. The C interoperability features, including the BIND(C,NAME="string") attribute, is the preferred choice for this. One can also use !DEC$ ATTRIBUTES ALIAS.

[blicks]

I totally agree with you and all the answers above.

Me personally would not walk the "case-SENSITIVE" way, since it is not good at all!

I managed to solve the problem by talking to the people responsible for the Fortran part of the implementation (the gave up after i showed them your beautifully formulated answers).

I thank you for your time and interest.

much obliged!

/Mikael

[JVanB]

While I agree that code that requires otherwise is not Fortran, there are non-Fortran codes that are case-sensitive and require some care in porting to Fortran. Microsoft has a habit of composing dummy argument names that are the same as their type names except for case. I saw in an old version of kernel32.f90 that Intel had worked around this by changing the type of, for example, HWND to be INTEGER(HANDLE), but this led to some bugs. Have those bugs been fixed since? Does Intel have a document on how it renames Windows data types so that a user doesn't have to look them up on a case by case basis?

[Steven_L_Intel1]

Repeat Offender, I don't know what you mean by "bugs". As I mentioned earlier, the Fortran language as of Fortran 2003, as well as some Intel extensions, make it easy to call routines with mixed-case names in other languages. This is not the same as making local Fortran identifiers mixed-case, as was the original request.

The Win32 API modules define KIND value constants for most of the Microsoft conventions, though I'll agree that we don't have all of them. Typically when you have something starting with H it's a handle and INTEGER(HANDLE) is the correct usage.

[JVanB]

The bugs comment was due to carelessness on my part.I looked at the declaration for GetOverlappedResult and saw that argument #1 was declared as integer(HANDLE) hFile, and concluded without checking that it was a mistake. In fact Microsoft declares it as HANDLE hFile, so your module is correct.Am I the only one to trip over dummy arguments named hFile sometimes being typed HANDLE and sometimes HFILE? There are different possible approaches to naming these kind type parameters in Fortran. Intel's method requires the programmer to remember the exceptions like HFILE or LRESULTor to check the documentation every time. It might have been possible to use Microsoft's ultimate type names instead of stopping at HANDLE and SINT, but this would collide with Fortran names like INT and FLOAT, not to mention dummy argument names like HFILE and HWND, when upcased.

[Steven_L_Intel1]

We try to use the same names as MS, except when we can't. The argument names we try to keep the same. For derived types we try to have a convention of the MS name, upcased, prefixed with T_. I have found it generally works to look at the routine's description in MSDN and work out what the Fortran declaration is, though a look at the sources of the modules (which we provide, unlike some compilers...) to be sure.

We have had bugs in the Win32 API modules and we fix them when we can. I have a side project of updating the modules to reflect MS additions, but it's a huge task.