forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Please check if this crashes in your case
Goto page Previous  1, 2, 3
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1215

PostPosted: Sat Nov 23, 2019 5:26 pm    Post subject: Reply with quote

This is what the Fortran 95 Standard says about intrinsic functions:

Quote:
2.5.7 Intrinsic
The qualifier intrinsic signifies that the term to which it is applied is defined in this standard. Intrinsic applies to data types, procedures, assignment statements, and operators. All intrinsic data types, procedures, and operators may be used in any scoping unit without further definition or specification.


Please note the last sentence. Intrinsic entities are already defined at the beginning of compilation. The properties of intrinsics are stated with different wording at https://www.obliquity.com/computer/fortran/intrinsic.html :

Quote:
FORTRAN 77 provides a variety of intrinsic functions which may be used in any program unit. They are subject neither to type declarations nor IMPLICIT statements. Their names are not reserved keywords but to avoid confusion, it is inadvisable to use these names as arrays, constants, variables or user-defined external subprograms.


You wrote, "Do you now see my stance on that?"

I see it and I disagree strongly. If you don't care about the Fortran standard, and the Silverfrost documentation does not define and describe non-conforming behaviour that is to your satisfaction, you and I no longer have any basis for continuing this discussion. Make up your own language, get somebody to write a compiler for it, and try to recruit users for your new language.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2124
Location: South Pole, Antarctica

PostPosted: Sun Nov 24, 2019 1:52 am    Post subject: Reply with quote

Relax, mecej4. All reasonably follow standard with one hand and do something extra which is non-standard but could be in the future with another. You are too late by 3 decades with your advise to "make your own language, get somebody to write a compiler for it, and try to recruit users for your new language". This language is Ftn77-Ftn95. Very Happy Very Happy Very Happy Very Happy Smile The more developers violated standard the more successful they were. Fortran-like Matlab is an example.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2124
Location: South Pole, Antarctica

PostPosted: Mon Nov 25, 2019 9:04 am    Post subject: Reply with quote

For all who did not get the essence of our discussion here is the summary.

I had the code which periodically worked and not worked when it was necessary to give the code additional instructions via adding some parameters after the EXE name when you start the EXE. It's like when you for example add parameters

C:> PKZIP -a file.zip DATAfil.dat or
C:> FTN95.EXE /LINK /DEBUG

These parameters FTN77/95 recognizes from ancient ages when other Fortran compilers were just little babies and Fortran Standard was telling them : NO, anathema to you, do not do that, this will be non-standard!

The problem as it appears is in the inexplainable behavior of FTN95 which i find totally unacceptable and confusing to the extent that you for sure will not find the bug in decades as i did.

First, this is a side note: how we started programming after FTN77 using Fortran-90 modules. We put all subroutines into the modules and then USE them where needed and the program works OK. Before we placed all subroutines as independent subprograms before/after/aside the MAIN program and declared them REAL/INTEGER and EXTERNAL where we used them.

Now take the chair because you will fall when you get the point we discuss: when you expect that any subroutine you declared in the module will work if you USE this module you get that some Silverfrost-specific subroutine does not work because compiler "forgets" or "gets confused" with the "mangled" name reserved for this subroutine or function (Don't worry, it is not 100% reserved because you still can take this name but you will lose Silverfrost-specific functionality of course. You will shoot yourself into the leg but it's up to you )

Compiler forgets this subroutine name not because the user wrote "i like this name no matter what and will use it even if this name is LOG or WINIO@" but just "because" it got prefix, for example, MO! in front of its name (because the module above we called MO). This is called "mangles". But that's exactly like almost all other subroutines get mangled when declared inside the modules but things always worked OK (this is internal thing for the compiler and user even does not even need to know that). Can you imagine that? The own compiler left hand does not know what its right hand is doing. Why ? Possibly because Standard is requiring that modules mangle the names (but all do that, and it's ok). Should compiler be confused forgetting the name of subroutine specifically its own intrinsic functions (?!!!) Of course no way, that's not OK until some wounded into the head user will intentionally grab and overwrite the intrinsic name usually having the @ at the end). What is all this? This is either a design defect but also possibly just the trivial bug.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6088
Location: Salford, UK

PostPosted: Mon Nov 25, 2019 10:21 am    Post subject: Reply with quote

Dan

It is true that the person who wrote this part of FTN95 did not anticipate that you would make this mistake.

FTN95 has already been improved (for the next release) so that it will no longer be necessary to declare the return type of a native intrinsic function (anywhere).

If you do this within a module then in future FTN95 will politely tell you that you have erred.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1215

PostPosted: Mon Nov 25, 2019 12:01 pm    Post subject: Reply with quote

Dan and Paul,

Just now, I reread a month-old post of mine ( http://forums.silverfrost.com/viewtopic.php?p=27959#27959 ) in which I pointed out that FTN95 did not catch instances where a variable was declared in more than one module and was accessible by USE association from more than one module.

It just struck me, and is worth noting here, that section 11.3.2 of the Fortran 95 Standard, which I quoted there, may also cover Dan's complaint. Here is the pertinent quotation (emphasis added by me):

Quote:
Two or more accessible entities, other than generic interfaces, may have the same name only if the name is not used to refer to an entity in the scoping unit. Generic interfaces are handled as described in section 14.1.2.3. Except for these cases, the local name of any entity given accessibility by a USE statement shall differ from the local names of all other entities accessible to the scoping unit through USE statements and otherwise.

The last two words, "and otherwise", may cover Dan's code, since "otherwise" may include intrinsic entities. Do you agree with this interpretation, Paul?

As Paul already stated, Dan's code is in error, but FTN95 failed to catch the error. I confess that I failed to recognise the connection of the topic of this thread to Section 11.3.2 when writing my earlier posts in this thread.

I'll look up more recent Fortran standards to see how they address this question.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2124
Location: South Pole, Antarctica

PostPosted: Tue Nov 26, 2019 7:06 am    Post subject: Reply with quote

Thanks Paul for quick fix, thanks Mecej4 for discussion, and John for other options
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Goto page Previous  1, 2, 3
Page 3 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group