Why it is forbidden?
in [Fortran]
|
Prev: Caveat: Can One Dim Local Arrays Using Argument List Integers ??
Next: Spam removal - volunteer?
From: Richard Maine on 21 Dec 2009 14:06 Den7 <rrr7rrr(a)gmail.com> wrote: > On Dec 21, 2:55 am, robert.corb...(a)sun.com wrote: > > Sun Fortran has allowed "recursive" I/O involving > > different I/O units since the 2.0 release of Sun f90. > > It was hard to implement, but it was well worth the > > effort. > > > > Allowing recursive I/O to the same unit is an often > > requested extension, but it is problematic. > > Aren't my examples which write NOT IN THE SAME UNIT but into two > different I/O using have to be allowed? I'm having trouble parsing "Aren't my examples... have to be allowed?" See Bob's first sentence. They are allowed in Sun f90 as of its release 2.0. That's exactly what he said. If "have to be allowed" means something else, I'm not following it. No the standard doesn't say that they have to be allowed, if that's perhaps the intended meaning. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Terence on 21 Dec 2009 16:24 On Dec 21, 5:38 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > > Well, ENCODE was in the PDP-10 and PDP-11 Fortran IV (Fortran 66 more > or less) compilers. The first VAX compilers were Fortran 66, with > the Fortran 77 compilers coming along a little later. It might be > that the first ones ran in PDP-11 compatability mode. > > DEC had many extensions that IBM didn't have, ENCODE being one of them. > > (snip) > Yes. The BMD programs, rescued in their modified source from the old DEC library, usually contained the ENCODE function (easy to replace) and also the use of a special DEC version of SIGN (used to mark a blank entry as -0) which was NOT easy to replace and needed a complete replacement of the read statements with a subroutine call that first had to map the input field set from the format statement. Life would have been easier for this person, if the University of Los Angeles handn't dumped the original public domain source, in favour of the licensed BMDP versions. I even went their library stacks to seek them.
From: James Van Buskirk on 21 Dec 2009 16:32 "Den7" <rrr7rrr(a)gmail.com> wrote in message news:7af7ef60-ae7a-4287-95fc-9e19c71ef671(a)a39g2000pre.googlegroups.com... > So because I have to ask exactly what i need, the program-maximum is > (can i mask more?) > integer foo > external foo > open(11,file='11.out') > open(11,file='12.out') > write(11,*) foo(12) > end > integer function foo(i) > character*9 char_I > write(char_i,'(i9)') i > write(12,*,err=1000) char_i > 1000 foo=i > end I had this problem with recursive I/O when I wrote a code generator and posted it to the web so people could test it. It seemed illogical to me that f90 allowed the programmer to write recursive code but that f95 permitted compilers to implement I/O, even internal I/O, via fixed data structures that made all I/O operations non-reentrant. But if my code was going to be generally usable I had to modify my code. What I did was to create functions that could compose strings from numbers using specification functions to determine their LENs. Then I could compose a line of output via concatenation of several such strings (function results) and invoke a subroutine to print out a line of output. Worked really well except that some f95 compilers had problems with the specification functions or in general with complicated specification expressions. Here is an example adapted to your program: C:\gfortran\clf\recursive_io>type recursive_io.f90 module stuff implicit none contains subroutine write_unit(iunit,x) integer, intent(in) :: iunit character(*), intent(in) :: x write(iunit,'(a)') x end subroutine write_unit function compose_i4(x) integer, intent(in) :: x character(compose_i4_len(x)) compose_i4 write(compose_i4,*) x end function compose_i4 pure function compose_i4_len(x) integer compose_i4_len integer, intent(in) :: x character(range(x)+3) temp write(temp,*) x compose_i4_len = len_trim(temp) end function compose_i4_len end module stuff program test use stuff implicit none integer foo external foo open(11,file='11.out') ! open(11,file='12.out') ! BUG! open(12,file='12.out') ! write(11,*) foo(12) call write_unit(11,compose_i4(foo(12))) end program test integer function foo(i) implicit none integer i character*9 char_I write(char_i,'(i9)') i write(12,*,err=1000) char_i 1000 foo=i end function foo C:\gfortran\clf\recursive_io>gfortran -Wall recursive_io.f90 -orecursive_io C:\gfortran\clf\recursive_io>recursive_io C:\gfortran\clf\recursive_io>type 11.out 12 C:\gfortran\clf\recursive_io>type 12.out 12 For a more complex example, consider the usage of subroutine WX in http://home.comcast.net/~kmbtib/conv2c.f90 . -- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
From: Richard Maine on 21 Dec 2009 16:42 Terence <tbwright(a)cantv.net> wrote: > ...the University of Los Angeles Ain't no such animal. I assume you are probably referring to the University of California, Los Angeles (which I have a few degrees from). There is also California State University, Los Angeles (where 2 of my kids went for a while). And Google remids me that there is a City University Los Angeles. Thought I would check Google before posting just in case there happened to actually be a school by that name that I'd never heard of. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Den7 on 21 Dec 2009 16:46
On Dec 21, 11:06 am, nos...(a)see.signature (Richard Maine) wrote: > Den7 <rrr7...(a)gmail.com> wrote: > > On Dec 21, 2:55 am, robert.corb...(a)sun.com wrote: > > > Sun Fortran has allowed "recursive" I/O involving > > > different I/O units since the 2.0 release of Sun f90. > > > It was hard to implement, but it was well worth the > > > effort. > > > > Allowing recursive I/O to the same unit is an often > > > requested extension, but it is problematic. > > > Aren't my examples which write NOT IN THE SAME UNIT but into two > > different I/O using have to be allowed? > > I'm having trouble parsing "Aren't my examples... have to be allowed?" > > See Bob's first sentence. They are allowed in Sun f90 as of its release > 2.0. That's exactly what he said. If "have to be allowed" means > something else, I'm not following it. No the standard doesn't say that > they have to be allowed, if that's perhaps the intended meaning. > > -- > Richard Maine | Good judgment comes from experience; > email: last name at domain . net | experience comes from bad judgment. > domain: summertriangle | -- Mark Twain Yes, the last option I meant, trying to say that all my examples have to be allowed by the standard : looks like it's nothing wrong with writing into different I/O unit but of course i may miss some pitfalls. Would appreciate killing this idea reasons since i plan to suggest to developers to consider this as an extension, all compilers have many thousands of them, this compiler specifically As to your suggestion and encouragement to write own character <-> real/integer conversion utility - yep, this is great, it is probably the only what is left as a quick option. Unless may be if someone will find some the time and send me a DLL made in their compiler which supports just these two old functions encode and decode...will be great if they are not conflicting with the I/O |