forums.silverfrost.com

[JohnCampbell]

[DanRRight]

Paul,
Seems no one since 1990th used such a=b option and those who used did not ask the question why interface was needed when it is clear that sometimes it is not needed. Was interface required because Fortran compilers back then did not check subroutine arguments for consistency?

Great that Clearwin functions do not require interfaces, that would be a disaster

Eddie,
And there also exist linked lists also introduced hell lot ago which will crush not only the human brains but also the brains and cache coherency of pipelines of all predictive branches of processors https://en.wikipedia.org/wiki/Linked_list

John,
The question is why they need interface definition? I gave definition for a and b enough for Fortran to run the code unambiguously.

[Kenneth_Smith]

Dan,

[DanRRight]

Ken,
As valid by common sense code my example should work. I think it does not work just because possibly not all options were taken into account by FTN95 - no one in 20 years used this super rare twist besides geeks of 80th level, those who were paid by the number of lines of source code adding millions interfaces or those who wanted to make their codes unreadable to 99% fortraneers . I am not insisting to fix this as it looks like there is no any benefits for the codes with this (currently) cryptic syntax.

Or may be writing variables like this

[Kenneth_Smith]

Dan, That's an interesting twist to my last example. Another compiler does issue an ERROR at the call to sub1, "Explicit interface required for 'sub1': optional argument.

FTN95 with Checkmate does generate a run-time message "Attempt to call a routine with zero arguments when one is required". Which I agree does not help to pinpoint the need for an explicit interface.

One for the folks at Silverfrost to consider at some point.

[PaulLaidler]

gFortran does do better in this respect in that it generates a compile time error.

However, sub1 and the sub-program that calls it could be in separate files. In which case the caller knows nothing about the arguments at compile time and the compiler is unable to do any argument checking.

FTN95 deals with this via the runtime checking of CHECKMATE which may be unique.

As a general rule, sub-programs are separately compiled. If they reside in the same file then the compiler may do some cross referencing and indeed FTN95 does do this in most contexts but apparently not in this case.

For separate compilation and in the absence of an interface, the best that a compiler can do is to check that different calls to a sub-program are consistent in the number and in the type of the arguments.

[DanRRight]

Paul,
The gfortran gave diagnostics

[PaulLaidler]

Dan

I don't understand what you are saying.

1) Interfaces were introduced in Fortran 90.
2) Fortran compilers support Fortran 77.
3) For some features of Fortran 90, compilation requires an interface and both logic and the Standard naturally insist on this.

The sample program illustrates a case where FTN95 could give useful feedback but the bug is in the code not in the compiler. FTN95 is usually what you call "smart" in situations like this but (at the moment) not in this particular case.

[LitusSaxonicum]

Paul,

So that's "smartish".

Smart enough for me, though.

Eddie

[DanRRight]

Paul,
I'm trying to say that code does not complain if i define a and b in the module, it does not complain when i define a and b in CONTAINS like Ken revealed, but when i define a and b directly just one line before calling sub1(a=b) the compiler abruptly remembers the Standard and tells me that i forgot damn interface.
Sounds kind of unusual, right?
And the resolution i proposed is that despite asking for the interface is formally correct according to Standard but by the common sense compiler has to violate Standard and do not ask for interface just warning that in other circumstances in similar situations here could be an error (when two programs are in separate files). In my case with sub1(a=b) exactly there is no error in any circumstances as a and b are fully defined.

That how smart compiler should do. And FTN95 in many cases doing like that checking arguments of subroutines on match and mismatch. Can it do that at compile time instead of run time with /checkmate? Ideally it should.
Computers are not yet perfect but the humans are even worse. Analyzing not only my mistakes in my own codes but even driving mistakes recently made on 3000 miles trip i am sure Elon Masks self-driving software would not make any of my mistakes when i barely escaped collision or wrong turns . It would do its own mistakes if i'll fall asleep but this is different story

[PaulLaidler]

Dan

I think that I now understand what you are asking for.

But perhaps you are not understanding the idea of an interface.

An interface can be explicit via an INTERFACE statement. It can also be implicit when provided automatically via USE and a MODULE or by a CONTAINS in a program or sub-program.

The idea that your code should provide a warning and not an error at compile time is interesting. It would be an extension to the Standard and might have its downside.

[JohnCampbell]

My understanding of this latest thread is that �a� is an optional argument for the examples to work.
So in the calling routine, �a� doesn�t need to be declared, only �b�.
Should �a� be declared optional for this to work properly?

[mecej4]

It seems to me that Dan is confused by two features of subroutine argument lists that were added in Fortran 90 (and were not present in Fortran 77). One feature is that some dummy arguments may be given the attribute OPTIONAL. The other feature is that argument association may be controlled by position in the argument list, as in Fortran 77, OR by keyword. I think that Dan is unaware of association by keyword.

Dan is free to avoid these "new" features of Fortran 90 when he writes Fortran code. When, however, he has to collaborate with others who use these new features, he will have to understand the properties of these new features.

Here is a small program to shed some light on these features.

[Kenneth_Smith]

I found this via google which explains the logic, particularly when mixing optional and non-optional arguments.

[DanRRight]

We are discussing new or rare features to find why people use them and are they worth using. If someone uses them my immediate question is why? Even if this is just the personal programming style then there still could be reason for that. I observed couple programs recently which heavily use all new features. When the author is present and supports these programs are looks kind of ok but the fun is - rarely who to no one else uses them even though they are open source.

When i asked authors why they use this or that new features they can not explain that. Meantime i see if they would not use them the code would be much more clean and easy. I also see other much more dangerous consequences for that when adding some key things to the code which was easy in previous "not so modern" versions of the same code become difficult to add (or they are even absent in the new and "modern" versions and the authors admit "adding that would be difficult...". Of course difficult, when you added 100 Linked Lists, derived types and pointers pointing on pointers .

Another observation - it takes weeks and months even for authors to do elementary things with such "modern" codes.

As to this last example - it was almost nothing to argue about here besides that as soon as you use keywords the subroutine needs interface or be in the module or CONTASINS because of "All shut up, I am the Fortran Standard and I say so" while my example used just one single argument and it does not matter what keyword you will use there all arguments and variables when calling SUB1 (a) or SUB1(a=b) is A keyword or an actual argument all were 100% defined there and asking for interface (which could be reasonable in other complex cases of many optional arguments could be reasonable or obligatory) in this simplest example was not so needed. I pointed out that the future compilers with AI will just issue a warning.

By the way, I have not heard from anyone that they use keyword arguments and claim it worth programming like that. But this thread is exactly to push everyone to use them and find how useful they are.