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 00:48 Richard Maine <nospam(a)see.signature> wrote: > glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > > > As to multiplication, you can't call a function in the middle of > > a multiply operation. > > Well, yes you can if the multiply operation is implemented via a defined > operation (which you can't do for the cases where the standard defines > an intrinsic multiply.) > > If you happen to do a defined operation for multiply, you will run into > the same kinds of limitations. In particular, your multiply routine may > not recursively invoke itself (unless it is explicitly declared to be > recursive). This is indeed something that could relistically come up if > one was doing defined operations. Oh. It occurred to me right after posting the above that it might be worth pointing out another relationship between these matters. The f2003 feature of allowing recursive internal I/O was directly related to defined I/O (which in turn is related to defined operations). In particular, when defined I/O was added to f2003 (which was a subject of controversy, but that's a side issue for the current topic), one particular case of recursive I/O pretty much had to be allowed. Namely, you really have to be able to do I/O in a defined I/O routine or the whole thing becomes pointless. Once the camel's nose was in that particular door, the argument was made that this required the underlying functionality be supported, so might as well also allow the case that "everyone" asks for - namely internal I/O like in the OP's post. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Richard Maine on 21 Dec 2009 00:51 Richard Maine <nospam(a)see.signature> wrote: > he case that > "everyone" asks for - namely internal I/O like in the OP's post. Oops. I didn't go back and check the OP's post before writing that. His case isn't internal I/O after all. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 21 Dec 2009 01:38 Richard Maine <nospam(a)see.signature> wrote: (snip) > Also note that the restriction in question originated several decades > ago. There existed major compiler implementations of the time where > reentrancy was a major pain. Even if one might argue (as people have) > that such compilers could have been done otherwise, that wasn't the > question at hand. Arguing about what should have been different in the > past tends to be pointless (unless one first spends a lot of time in > understanding the context of the era). Most likely in Fortran II when functions written in Fortran were added to the language. Reasonably likely only one buffer was used for all I/O operations, and statically allocated. (snip) >> How old VAX ENCODE is implemented in your compiler? Is it done via >> internal write or by some proprietary other non-I/O way? > That question doesn't really make much sense. Encode is a bit of > language syntax, as is internal I/O. You don't implement one piece of > language syntax via another (well, not normally; when you do, that's > generally called a preprocessor). And encode preceded internal write, so > it scarely would have been implemented that way. 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) -- glen
From: robert.corbett on 21 Dec 2009 05:55 On Dec 20, 8:56 pm, Den7 <rrr7...(a)gmail.com> wrote: > Please look at this code, why this code is forbidden (in my compiler > at least) ? > > integer foo > external foo > > open(11,file='11.out') > open(12,file='12.out') > write(11,*) foo(12) > end > > integer function foo(i) > write(12,*) i > 1000 foo=i > end function foo > > Even if i write into character variable (so called internal write or > something like that) i have the same problem. > Even more, if i make > > write(12,*,err=1000) i > > i still have the crash. How about your compiler? > > The error is "The function called from within an I/O statement has > itself performed an I/O". > It sounds to me as silly as this: "The function called from within > multiplication has itself performed a multiplication", but there could > be nasty reasons for forbidding this kind of I/Os requiring > multithreading or so. > > How old VAX ENCODE is implemented in your compiler? Is it done via > internal write or by some proprietary other non-I/O way? In other > words, can you check if this code below is also crashing, and if it > does, is it crashing on ENCODE line statement or on the next lines > with WRITE statement? Or may be your compiler allows all these writes > and you do not experience a problem at all despite the standard may > forbid that? (Please also check syntax of this snippet, i can not run > it, my compiler does not support these long forbidden ENCODE/DECODE > extensions) > > open(11,file='11.out') > open(12,file='12.out') > write(11,*) foo(1) > end > > integer function foo(i) > character*9 CHAR_I > > ENCODE (9,1,CHAR_I) i > 1 format (i9) > write(12,*) char_i > > write(12,*) i > > foo=i > end > > TIA ! 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. What should happen if a program closes a file in the middle of writing to that file? One case that could be allowed and that seems to be what most people who ask for the extension want is to allow a formatted WRITE on a unit which is already being used in another formatted WRITE. Bob Corbett
From: Tim Prince on 21 Dec 2009 09:06
glen herrmannsfeldt wrote: > (snip) > >>> How old VAX ENCODE is implemented in your compiler? Is it done via >>> internal write or by some proprietary other non-I/O way? > >> That question doesn't really make much sense. Encode is a bit of >> language syntax, as is internal I/O. You don't implement one piece of >> language syntax via another (well, not normally; when you do, that's >> generally called a preprocessor). And encode preceded internal write, so >> it scarely would have been implemented that way. > > 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) As I recall, there were 2 major incompatible versions of ENCODE among the 3 brands of f66 compilers I used which supported that keyword. This was one non-standard feature which went out of use rapidly when f77 compilers became available. |