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 

Suggestion for FTN95 extensions

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions
View previous topic :: View next topic  
Author Message
DanRRight



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

PostPosted: Sat Mar 09, 2013 4:47 pm    Post subject: Suggestion for FTN95 extensions Reply with quote

How about allowing not to use parentheses in format specification like in this example

read (75,'(i6)') variable

and allowing just this

read (75,'i6') variable

They are absolutely useless and only add you troubles with complex formats to count left and right parentheses
Back to top
View user's profile Send private message
davidb



Joined: 17 Jul 2009
Posts: 560
Location: UK

PostPosted: Sun Mar 10, 2013 10:34 pm    Post subject: Reply with quote

The outer parentheses are required syntax. Without them Format reversion would not work in a consistent way for cases where there are no "internal" ones.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Tue Mar 12, 2013 2:27 pm    Post subject: Reply with quote

I do not see the problem here, can you show an example killing the idea?

To me, instead of format control to return to the initial opening parenthesis of the format specification in this case (which is useless because contains no information) it will return to the first symbol of the format specification which is the same thing Smile

Quote:
Reversion
When the last closing parenthesis of the format specification is
reached, format control determines whether more I/O list elements
are to be processed. If not, format control terminates. However,
if additional list elements remain, part or all of the format
specification is reused in a process called format reversion.

In format reversion, the current record is terminated, a new one is
initiated, and format control reverts to the group repeat
specification whose opening parenthesis matches the next-to-last
closing parenthesis of the format specification. If the format
does not contain a group repeat specification, format control
returns to the initial opening parenthesis of the format
specification. Format control continues from that point.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Wed Mar 13, 2013 1:16 am    Post subject: Reply with quote

My favourite extension to the fortran standard is to use the DO variable as an alternative name, such as:
Code:

DO I = 1,n
  DO J = 1,m
    IF (logical) CYCLE I
...
  END DO J
  DO J = 1,m
    IF (logical) CYCLE J
...
  END DO J
END DO I


For CYCLE or EXIT, the possible values of a DO name is limited to the nest level of DO loops in use. There should be no confusion where there are two J DO loops in the example above.
The inclusion of "END DO variable" improves the readability of the code.
Over many years I have never been able to convince anyone of the value of this change. Apparently improving readability of code is not important.
I sometimes resort to "END DO ! I"

John
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Wed Mar 13, 2013 3:53 pm    Post subject: Reply with quote

...because it takes time to comprehend, estimate if this will not hit the performance, brake legacy codes etc, and for users to get larger programming base with CYCLE and EXIT which are still not as very common etc. Plus developers have other hatching ideas which are almost ready to be implemented and they are permanently estimate which one is more urgent based on users demand or more easy to implement. The suggestion makes sense. I suggest you ask again later.

As to END DO I, that is also very good suggestion. To make something similar I almost always use comments like these END DO ! I=1,n_divisions or ENDIF IF ! (Lorentz.gt.Doppler) then or Else ! (dwavelengthInit.gt.1.e3) all the time, i'd die without them. With this respect the readability of older loops and IFs wiith the label is much better then labelless ENDDO and END IF. I remember the discussion about that years ago and think the advantages of labelless approach is pure BS because it kills readability in larger complex codes with many DOs and IFs . But since people and myself adopted it, your suggestion to improve readability of labelless DOs should be definitely pushed forward
Back to top
View user's profile Send private message
davidb



Joined: 17 Jul 2009
Posts: 560
Location: UK

PostPosted: Sat Mar 16, 2013 12:25 am    Post subject: Re: Reply with quote

[quote="DanRRight"]I do not see the problem here, can you show an example killing the idea?

The Fortran standard allows anything to be included after the trailing bracket. Like this contrived example:

Code:

write(*,'(I5) THIS IS IGNORED') 10


The following code needs the brackets to work. The first format specifier is seen as the character array '(I5) (F5.0)'. Without the brackets it would look like 'I5 F5.0' which would be an error. A compiler is not required to detect this error (how could it?) but a run time error should be generated.

The standard says:

"If the format specifier references a character array, it is treated as if all of the elements of the array were specified in array element order and were concatenated. However, if a format specifier references a character array element, the format specification shall be entirely within that array
element."

Code:

character(len=6) :: fmt(2)
fmt(1) = '(I5)';  fmt(2) = '(F5.0)'
write(*, fmt) 10   !< Here the format specifier is '(I5)  (F5.0)'
end

_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
davidb



Joined: 17 Jul 2009
Posts: 560
Location: UK

PostPosted: Sat Mar 16, 2013 12:46 am    Post subject: Re: Reply with quote

JohnCampbell wrote:

Over many years I have never been able to convince anyone of the value of this change.
John


You can already do this with Silverfrosts FTN95 John so someone has listened to you. The following works for example

Code:

i: do i=1, 100
j:    do j=1, 100

          exit j

      end do j
   end do i

_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Mar 16, 2013 3:21 am    Post subject: Reply with quote

It has no sense to keep the parentheses just to able to write trash in the format which has no purpose whatsoever. I'd understand that parentheses worked at least somehow, say, as separator making the following format equivalent to '(i5,i10)' for this code to work properly

Code:
        write(*,'(i5)(i10) junk') 12, 100000000
   end


but they don't, the (i10) part is similarly useless and is ignored as the word "junk" after it. How such proposal to allow junk in format came through Fortran Standard committee while object oriented features still did not? :/

And that's cool

[quote="davidb"]
davidb wrote:

Code:

i: do i=1, 100
j:    do j=1, 100

          exit j

      end do j
   end do i


Last edited by DanRRight on Sat Mar 16, 2013 9:47 pm; edited 1 time in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sat Mar 16, 2013 10:26 am    Post subject: Reply with quote

Providing a name for a do construct is part of the Standard.

Other compilers do not allow you to use a name that is the same as the name of a variable but as far as I know this is not explicitly excluded in the Standard.

So the following should be portable...

Code:
ii: do i=1, 100
jj:    do j=1, 100
          exit j
      end do jj
   end do ii
Back to top
View user's profile Send private message AIM Address
DanRRight



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

PostPosted: Sat Mar 16, 2013 9:41 pm    Post subject: Reply with quote

1) I'd use this immediately but need to know how long this labeling exists to make sure this will be portable. When this emerged in the Standard? Will this labeled DO work with FTN77 or gFortran which is mostly 77 ?

2) Do similar readability improvements exist for IF-THEN-ELSE-ENDIF ?
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sun Mar 17, 2013 6:57 am    Post subject: Reply with quote

David,

You use of named do does not work easily with the example I gave:
Code:
DO I = 1,n
  DO J = 1,m
    IF (logical) CYCLE I
...
  END DO J
  DO J = 1,m
    IF (logical) CYCLE J
...
  END DO J
END DO I

In this example there are 2 DO J loops, but only one of them can be the valid cycle of exit destination.

My point is that the use of names on CYCLE, EXIT or END DO is an inefficient use of names and the DO subscript would be a much better name for loops where a subscript is used. It is improves teh readability of the code.

John
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 -> Suggestions All times are GMT + 1 Hour
Page 1 of 1

 
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