Path: utzoo!attcan!uunet!husc6!uwvax!dogie!uwmcsd1!ig!agate!ucbvax!decwrl!pyramid!oliveb!intelca!mipos3!omepd!bobdi From: bobdi@omepd (Bob Dietrich) Newsgroups: comp.lang.pascal Subject: Re: File semantics Message-ID: <3596@omepd> Date: 20 Jun 88 20:36:33 GMT References: <6029@uwmcsd1.UUCP> Reply-To: bobdi@omepd.UUCP (Bob Dietrich) Organization: Intel Corp., Hillsboro, Oregon Lines: 49 Just glanced over your notes and have few comments: 1) What is the point you are trying to make? 2) Your notation bears a lot of similarity to the way files and operations on files are specified in the ANSI/ISO standards and in the Extended Pascal draft. There may be some similarity to the Axiomatic Definition, but I can't remember what was done there, and don't have a copy handy. 3) Files in the standards are specified as a triple consisting of a left sequence, a right sequence, and a mode. Mode is Inspection or Generation, corresponding to your READ and WRITE modes. Extended Pascal adds an Update mode. 4) Operations on files are stated in terms of pre and post-conditions on these triples. Usually these are axiomatic, with additional conditions (such as errors) stated in (standardese) English. 5) You might be careful in a couple of areas. One is that the ANSI and Extended Pascal interpretation is that for things like read, a "reference" is established to the file variable and then the operations performed. The intent is to have predictable behavior for things like read( f[i], i, j) where f is an array of files and i and j are variables. This is a possible problem with the expansions you suggest. The other potential problem area you may or may not have addressed is lazy I/O (actually, just I). The standards carefully leave this possibility open, which means that a processor may actually do external file operations (if that is what your file sequence is operating on) when eof or eoln is invoked. Again, this may not be a problem for your notation; I haven't looked very closely. 6) I don't believe you account for such things as the fact the file buffer is undefined after a put. Please don't construe these comments as negative. I am always pleased to see someone putting a little thought into a problem. I'm just trying to offer suggestions for improvements and point out similar work. Bob Dietrich Intel Corporation, Hillsboro, Oregon (503) 696-4400 or 2092(messages x4188,2111) usenet: tektronix!ogcvax!omepd!bobdi or tektronix!psu-cs!omepd!bobdi or ihnp4!verdix!omepd!bobdi