From: dxforth@gmail.com   
      
   On 26/07/2025 4:29 pm, Anton Ertl wrote:   
   > ...   
   > The specification requires:   
   >   
   > |If the operation succeeded, flag is true and ior is zero.   
   > [...]   
   > |If the operation is initiated when the value returned by FILE-POSITION   
   > |is equal to the value returned by FILE-SIZE for the file identified by   
   > |fileid, flag is false, ior is zero, and u2 is zero.   
   >   
   > In the case of u1=0, both conditions can be true, and the   
   > specification is contradictory.  VFX, Gforth, and NTF apparently give   
   > priority to the first statement, SwiftForth and Win32Forth to the   
   > second.   
   >   
   > The specification should not be contradictory.  It should specify for   
   > this case whether flag should be true or false, or, if no consensus is   
   > reached, it should explicitly state that both results are acceptable.   
   >   
   > READ-LINE seems to be a particularly problematic word, with many   
   > discussions about its specification over the years.  Maybe the quality   
   > of the specification is not up to the quality of the rest of the   
   > standard, but I believe that the root cause of the problem is that   
   > this word has to satisfy too many requirements:   
   >   
   > It should not ALLOCATE (because small Forth systems are not expected   
   > to provide ALLOCATE, so it was designed to work with a given buffer.   
   > But it should also be able to use it to read lines longer than this   
   > buffer.   
   >   
   > Does anyone programming for a system without ALLOCATE actually read   
   > and process longer lines with READ-LINE?  Or do they just use   
   > READ-LINE with a certain buffer, and specify that the input must not   
   > have lines longer than the buffer?   
   >   
   > In the latter case it would have been better to have two words: A word   
   > for reading lines of up to u1 characters into a given buffer (mostly   
   > like READ-LINE, but with some provisions for reading extended lines   
   > simplified away (maybe resulting in an ior<>0).  And a word that reads   
   > and ALLOCATEs an arbitrarily long line.   
      
   READ-LINE is a compromise for small systems.  More efficient would be   
   a buffered system which reads large chunks of the file and parses out   
   a line (not unlike PARSE).   
      
   > Of course, that's water down the river.  As it is, we should revise   
   > the specification of READ-LINE to address the ambiguities.   
      
   Revision in the absence of practice may do more harm than good.  I've   
   dealt with several implementations of READ-LINE.  All give subtly   
   different results.  ANS seems pedantic on EOF returning both u2=0 and   
   flag=0.  The TC reiterated this in response to an RFI.  But why?  Who   
   checks u2 for EOF?   
      
   Omitted from the ANS spec is any mention of EOF characters for systems   
   that employ it e.g. CP/M and MS-DOS.  And if READ-LINE encounters such   
   there should be a way to report it.  I've had to write custom routines   
   to do just that.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)