Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: READ-LINE when u1=0
Date: Sat, 26 Jul 2025 06:29:03 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 107
Message-ID: <2025Jul26.082903@mips.complang.tuwien.ac.at>
References: <68839b81$1@news.ausics.net> <2025Jul25.170641@mips.complang.tuwien.ac.at> <6884346a$1@news.ausics.net>
Injection-Date: Sat, 26 Jul 2025 09:08:58 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="201de0e20d1073fc96f2fe1a707d6e87";
	logging-data="2472578"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+drmkv2C0WV7kiBTOKhsbC"
Cancel-Lock: sha1:gg6dhwirl1vm8aUL2ZfHJ1dI1Xk=
X-newsreader: xrn 10.11

dxf <dxforth@gmail.com> writes:
>If the result differs but with no harmful effect then what would
>you call that?

If the the behaviour of an implementation differs from what is
specified, I call that a bug.

>0 value fid
>
>: print cr rot 2 .r ."  ->" swap 2 .r 3 .r ;
>
>: test
>s" foo.txt" r/w create-file throw to fid
>s" foobar" fid write-file throw
>fid close-file drop
>
>s" foo.txt" r/o open-file throw to fid
>page
>0  pad over fid read-line throw print
>10 pad over fid read-line throw print
>0  pad over fid read-line throw print
>1  pad over fid read-line throw print
>fid close-file drop cr
>;
>
>test
>
>\\
>
>SwiftForth
> 0 -> 0 -1
>10 -> 6 -1
> 0 -> 0  0
> 1 -> 0  0
>
>VFX
> 0 -> 0 -1
>10 -> 6 -1
> 0 -> 0 -1
> 1 -> 0  0
>
>Gforth
> 0 -> 0 -1
>10 -> 6 -1
> 0 -> 0 -1
> 1 -> 0  0
>
>NTF
> 0 -> 0 -1
>10 -> 6 -1
> 0 -> 0 -1
> 1 -> 0  0
>
>Win32Forth
> 0 -> 0 -1
>10 -> 6 -1
> 0 -> 0  0
> 1 -> 0  0

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.

Of course, that's water down the river.  As it is, we should revise
the specification of READ-LINE to address the ambiguities.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2025 CFP: http://www.euroforth.org/ef25/cfp.html