Ambiguous condition? If not, what should be the result
and what is it good for?
dxf <dxforth@gmail.com> writes:
Ambiguous condition? If not, what should be the result
AFAICS u1=0 is not specified as ambiguous condition, and I don't see
a reason that would make it ambiguous.
The results depend on the state of the file.
1) Either a non-zero ior, or
2) ior=0, u2=0, and
a) flag=false under the specified condition
b) flag=true otherwise
and what is it good for?
If you ever meet programmers that call READ-LINE with u1=0, ask them.
The last time I asked about a usage that appeared pointless to me (an
empty DOES> clause), the author had no satisfying explanation.
If the result differs but with no harmful effect then what would
you call that?
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
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.
...
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.
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.
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
dxf <dxforth@gmail.com> writes:
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?
Reporting EOF only when the input has been exhausted before READ-LINE
means that there is no special handling needed for the last line
(assuming you want to process it the same way as the other lines).
Omitted from the ANS spec is any mention of EOF characters for systems
that employ it e.g. CP/M and MS-DOS.
That's in line with the way that the standard deals with different
newline representations: It does not mention them in the normative
part, exactly because they are different and therefore problematic to standardize.
For EOF it's the same. There's a way to report EOF no matter how EOF
is represented in the OS, but no standard way to find out anything
about the representation.
And if READ-LINE encounters such
there should be a way to report it.
If you think that the existing EOF handling is insufficient, make a
proposal. And make a good case why you consider the existing EOF
handling insufficient. It has been sufficient for me up to now.
4tH
0 -> 0 1
10 -> 6 1
0 -> 0 1
1 -> 0 0
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,064 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 153:20:38 |
| Calls: | 13,691 |
| Calls today: | 1 |
| Files: | 186,936 |
| D/L today: |
2,526 files (731M bytes) |
| Messages: | 2,411,055 |