Dysfunctional functions

I spent a baffled hour or so last week trying to find a bug that I had suddenly inadvertently introduced into my code. The beastie was generating error messages that seemed to suggest something catastrophically wrong, up to and including internal compiler errors. Once I realised what I had done - changed an *argumentless *subroutine to a function - it was easy to put things right again. But I was left thinking that the compiler had not done a very good job of diagnosing and handling the error. Try and compile the following code:

  integer function a
  a = 2
  return
  end function a

and FTN95 (v5.01) will report as follows:

... : error 820 - 'A' found after FUNCTION where a comma was expected ... : error 491 - RETURN cannot be inside a PROGRAM block ... : error 778 - END FUNCTION found where END PROGRAM was expected ... : error 283 - A must appear in a type declaration because IMPLICIT NONE has been used

This collection of error messages strike me as unhelpful verging on misleading:

• why would the compiler expect a comma after the keyword FUNCTION?

Presumably it thinks the line is defining two integer variables named 'function' and 'a'. But then:

• why does it think this is a program block when it does not start with the keyword PROGRAM?
• similarly, why does it expect END PROGRAM without a matching PROGRAM?

What do others think?

While I see your point of view bruce I lean toward anyhing that helps debugging and speeding up development time.

Given 'function' has a special meaning I don't think it unreasonable to have a 'have you missed a () ?' type error message, a bit like latex would.

or maybe 'functions must have () in definition' this would only have to be triggered after the other error messages.

I might even go further and have the compiler suggest as a comment that functions , subroutines and variables have poorly chosen names like IF or ELSE or FUNCTION I have seen code that compiles with these keyword function names but they ain't half hard to read and maybe the compiler should make readablility suggestions that would be as simple as this to pick up.

carl

Quoted from brucebowler

Quoted from sparge

• why does it think this is a program block when it does not start with the keyword PROGRAM?
• similarly, why does it expect END PROGRAM without a matching PROGRAM?

What do others think?

• it's not a function or a subroutine, therefor there must be an (implied, optional) PROGRAM statement.

• Since there's an implied PROGRAM statement, the END should be an END PROGRAM, not an END FUNCTION.

It all seems very logical to me. What would you expect the error message to be?

Bruce

I didn't realise the PROGRAM statement was optional! But I just cracked open Metcalf & Reid, and you're right. Incidentally, as I read the book, if the program statement is omitted, the END should be - just an END.

And remember this is the simplest isolated example. In reality, it was one bit of a module - not so obvious how to interpret the error message. Also don't forget I said that I was getting internal compiler errors some of the time when I was trying to figure out what I had done wrong. Whatever shortcomings there may be in my knowledge of FORTRAN syntax, internal compiler errors should not happen. They misled me very badly into thinking there was something far more seriously wrong than there actually was.