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