bobal@microsoft.UUCP (Bob Allison) (10/03/89)
Well, there has been some (well-deserved) speculation on where non-advancing I/O came from, and since I was in charge of the Control Constructs and I/O subgroup at that time, I can give a mildly biased account of what happened. There was a lot of international (i.e., WG-5) and public comment pressure for some form of "stream I/O". We resolved to do something about it. However, it quickly became apparent that there were about six different definitions of what "stream I/O" meant, and no one standard solution (i.e., already implemented solution in FORTRAN or C) seemed to fit enough people's descriptions of what they really wanted. So, we decided to propose a fundamental mechanism which allowed people to build up the functionality they wanted without our having to resort to defining new statements or intrinsic functions (wow, don't even suggest trying to put in intrinsic functions which perform I/O functions; that turned out to be a nasty problem of documentation and functionality). Late one night we came up with non-advancing, added SIZE=, and pretty soon had a description which covered most people's needs (at that time, there were even section notes describing what we expected implementations to do with a terminal, which was what to do what PROMPT= did; I don't know what happened to those section notes; they are gone in S8.112). It fit a model where you could do things like GETCHAR/PUTCHAR, like DEC's '$' (or others '\') edit descriptor, and provided hooks for a future implementation more like C's getchar/putchar (don't interpret the bits, just give them to me) by leaving unformatted as undescribed. This was considered a good enough compromise by the really vocal proponents of each scheme (I remember one guy had one specific application in mind and would vote against anything which wouldn't support this particular application and coding style) and was voted in. Frankly, we were too chicken to fool with asynch I/O and that's why it is not in. No one even got so far as to attempt to figure out what an appropriate strategy would be (BUFFERIN/BUFFEROUT or more like DEC's ASSOCIATEVARIABLE scheme). By the time the membership had shifted enough to acknowledge that this might be a real issue, it was too late in the game. Finally, whether non-advancing I/O actually helped allow varying character modules has never been clear, since you can't overload the assignment operator for structures (it's intrinsically defined) and I've never seen a plausible module scheme for varying character. This might help, but there are so many other roadblocks that I doubt it will make a difference. (If anyone is really interested in the issue of implementing varying character in modules we can get into it, but at the latest WG-5 meeting I believe there was a demonstration by a European and he was pretty surprised when he found out his code didn't, and couldn't, work). Bob Allison uunet!microsoft!bobal PS. Now, after having really slaved to get non-advancing I/O in at Palo Alto, I'm still not really sure I did the right thing. Folks, that's what public review is for; please respond (both positive and negative responses are useful) about this feature, and any others which you know about (even indifference is a response we're interested in).