Re: detect Inf or NaN

"James Giles" <jamesgiles@xxxxxxxxxxxxxxxx> wrote in message news:iwVUi.288304$ax1.60258@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Craig Dedo wrote:
"James Giles" <jamesgiles@xxxxxxxxxxxxxxxx> wrote in message
news:CoPUi.286689$ax1.162980@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...
Of course, the names shouldn't have been so verbose in the first
place. You know they're IEEE functions because of the MODULE
you got them from. You don't need them to carry around that
information in their names.

I strongly disagree. The names of the IEEE procedures and other
named thingos are excellent examples of proper naming practices. They follow all of the criteria of recommended best practices for
good names. One software development standard, the _OpenVMS
Programming Concepts_ manual, specifically recommends that procedures
that conceptually belong together should share a common prefix. In
OpenVMS terminology, this conceptual grouping is called a "facility".
Each facility in a particular organization should have a unique
prefix and all procedure names should start with the facility prefix.

Excellent advice for languages like C where there are no module
facilities. Indeed, things in Fortran - like external procedures,
COMMON block names, and MODULE names should do so as
well. I can well remember the trouble of designing proper
naming conventions for programs given that procedures and
common blocks were limited to 6 character names. The advice
that things filling up the global namespace need to be carefully
named is hardly a newsflash.

But the contents of a MODULE don't reside in the global namespace.
The issues important for the selection of their names are different.

I disagree that this advice is more appropriate for C than other languages. OpenVMS is the one operating system that I know of that is truly language independent. It has a Language-Independent Procedure Calling Standard. The OpenVMS Programming Concepts Manual is written for programming under OpenVMS generally and has examples in several of the languages that are supported under OpenVMS.

This is in sharp contrast to the various Unixes, which are strongly C-centric and to Windows, which has gone from being C-Centric -> C++-centric -> C#-centric.

I disagree that issues about names for module procedures are very much different from names of external procedures. My philospophy for creating procedure names at all scoping levels is summarized by this sentence from the 2nd edition: "Overall, the emphasis when creating a routine name should be to make the name as clear as possible, which means that you should make the name as long or short as needed to make it understandable."

I mentioned Steve McConnell's _Code Complete: A Practical Handbook
of Software Construction_ yesterday in a different thread. Both
editions of this book have extensive discussions of recommended
practices for choosing good names. They are in 1st ed., ch. 9, "The
Power of Data Names" and 2nd ed., ch. 11, "The Power of Variable
Names". For procedure names, see also 1st ed., sec. 5.2 and 2nd ed., sec. 7.3.

And this was a book written specifically with *Fortran* in mind? Or
is it advice more relevant to writers of languages like C (where it's
valid advice indeed). To be sure, names should be mnemonic for the
thing they name. In a modular language that usually shouldn't need to
include where they came from. It is certainly the case that how you
write a code for legibility depends a lot on the features and syntax
of the target language. There's no "one size fits all" advice for most
programming issues - including variable naming conventions.

Both editions of this book were written to give guidance for programming construction practices generally. The 1st edition uses examples in Basic, C, C++, Fortran, and Pascal. The 2nd edition examples concentrate on Java and the Microsoft Visual Studio languages, so Fortran is almost completely ignored in the 2nd ed. And, in the 1st edition, Steve McConnell has a decidedly negative view of Fortran. Still, in spite of this defect, both editions contain lots of good and useful recommendations about programming construction, and is solidly based on the best and most useful research results. Language-specific construction issues are explicitly identified in both editions.

You are also assuming that the source code that references the procedure names is close to the USE statement for one of the IEEE modules.

Actually I wasn't assuming that. I was assuming that, once ISNAN
is available within the standard I'll not be using any other one.
So, I won't have any difficulty telling what ISNAN is in use no matter
how far from the declarations I get. Ad-hoc tests for ISNAN will
have long been consigned to /dev/null.

I doubt very much that J3 will create a standard ISNAN() procedure. J3 is very reluctant to create synonyms. E.g., proposals to make the keyword CONSTANT as a synonym for PARAMETER have gone nowhere. Also, J3 has a lot of other work to do.

If you insist on using ISNAN() instead of IEEE_IS_NAN(), you have several choices:
1. Create your own procedure wrapper.
2. Use the module rename facility in each procedure.
3. Create your own module that simply USEes IEEE_FEATURES, IEEE_EXCEPTIONS, and IEEE_ARITHMETIC, with the renamings that you want.

Be aware, however, that using your own renamings instead of the standard names will result in difficulties for programmers who have to maintain code that you wrote.

Like all forms of communication what you should be concerned with
is what you are trying to tell your reader (listener), and what you can
assume that person already knows. If you keep telling your audience
things already known they tend to tune you out. It's a good idea to
avoid that. This also explains why this very thread is discussing
ways to give these things more manageable names.

I did keep my audience in mind. I do that every time that I write someting. Please remember that my message was posted to the newsgroup generally and not only to you personally. There are readers of comp.lang.fortran who may not be aware of what recommended best practices are in this area nor of what books may have been written on this subject.

--
Craig Dedo
17130 W. Burleigh Place
P. O. Box 423
Brookfield, WI 53008-0423
Voice: (262) 783-5869
Fax: (262) 783-5928
Mobile: (414) 412-5869
E-mail: <cdedo@xxxxxxxxx> or <craig@xxxxxxxxxx>

.

Relevant Pages

  • Re: Why Writers Buy Asbestos Undies
    ... why there were no OpenVMS books in their review database. ... rambling introductions to programming on OpenVMS in a number of ... programming languages: DCL, BASIC, Fortran, COBOL, C and C++. ... languages implemented on the operating system to match functionality ...
    (comp.os.vms)
  • Re: Why Writers Buy Asbestos Undies
    ... why there were no OpenVMS books in their review database. ... this guide to programming on an ... programming languages: DCL, BASIC, Fortran, COBOL, C and C++. ... languages implemented on the operating system to match functionality ...
    (comp.os.vms)
  • Re: The Future of Programming Languages and Web browsers
    ... thought was that this product demonstrates how programming for the web ... browser environment should be handled. ... concept for its own industrial strength BASIC language on OpenVMS. ... languages with web servers is all custom (I have done it with OpenVMS- ...
    (comp.os.vms)
  • Suggestions and Resources?
    ... Hi I'm 11 years old and love computers, and want to go into programming. ... I've tried C, C++, and other languages but their all too hard for me. ... Any advice is appreciated! ...
    (comp.lang.ruby)
  • Re: compiler for Chinese development language
    ... This relates to the development of vernacular ... Indian vernacular display, OS and programming languages. ... Bangla and other vernaculars. ...
    (comp.compilers)