Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!sharkey!bnlux0!bam From: bam@bnlux0.bnl.gov (Bruce A. Martin) Newsgroups: comp.lang.fortran Subject: Re: another side effect question Message-ID: <2068@bnlux0.bnl.gov> Date: 17 Aug 90 21:16:43 GMT Organization: Grumman SXLS @ Brookhaven National Lab, Upton, NY Lines: 48 In article maine@elxsi.dfrf.nasa.gov (Richard Maine) writes: >... > > A function must not be referenced within an expression appearing anywhere > in an input/output statement if such a reference causes an input/output > statement to be executed. > >... subtlety of this restriction that annoys me relates to internal i/o. >Internal i/o isn't "really" i/o. It is just doing format conversion, >taking advantage of the Fortran runtime capabilities that happen to also >be used for "real" i/o. Nonetheless, by the strict definitions of the >standard, internal i/o does fall under the above restriction. Thus, >I cannot do the following >... Ah, but formatting is usually implemented as a sort of co-routine process, wherein one procedure tracks along the iolist (pushing or pulling values) whilst another one keeps track of where it was in the format string. Both procedures affect the contents of some sort of internal line buffer (as well as file status, for non-internal I/O). If you think this is unnecessary overkill, remember that a format may contain such contex-sensitive nasties as TL and P (unless you want to have different rules for internal I/O and probably different routines for their formatting). If the evaluation of an iolist item causes I/O -- even internal I/O -- then the format cracker would be reentered. OK, I know it could have been done with reentrant library routines, but that was a more general a cost tradeoff that went the other way when Fortran 77 was standardized. Today, it probably wouldn't cost very much to make everything reentrant, and I wouldn't be surprised to find that many Fortran processors already can handle it. In any event, it's not so simple to allow it just for internal I/O. > >... a function called in some context isn't even >allowed to print out an error or debugging message (and most routines >of any substantial content have places where error or debugging messages >are appropriate). Yes, that irks me too. But it's hard to allow the "good" cases and make only the bad ones illegal. I guess what's really desireable is general recursion and reentrancy of procedures, not rule relaxations for seemingly harmless special cases. >Richard Maine >maine@elxsi.dfrf.nasa.gov [130.134.64.6] Bruce A. Martin (bam@bnlux0.bnl.gov)