[MLton] Bug: TextPrimIO does not distinguish between EOF and no data

[Matthew Fluet]

On Tue, 11 Dec 2007, Ville Laurikari wrote:
> I dug around a bit, and found out that it seems that a readArrNB made
> with PrimIO (in basis-library/io/prim-io.fun) never returns NONE (to
> signify no data), but always returns SOME _.  In case of no data, we
> get SOME 0 which means EOF.  This readArrNB is implemented as
>   SOME (SOME o (readArr "readVecNB"))
> Am I just confused or is this the problem?  If the primitive reader
> does not distinguish between EOF and no data, TextIO surely cannot
> either.

Vesa diagnosed and fixed the actual bug in the ImperativeIOExtra 
layer (i.e., the buffered ImperativeIO layer used when the underlying 
StreamIO.instream is never extracted).  Nonetheless, to clear up the 
confusion about readArrNB:

basis-library/io/prim-io.fun:122:
                 readArrNB = SOME (SOME o (readArr "readVecNB")),
This is the readArrNB for PRIM_IO.openVector.  A vector-as-reader never 
blocks, so readArrNB always returns SOME _.

basis-library/io/prim-io.fun:149:
                 readArrNB = SOME (const "readArrNB" (SOME 0)),
This is the readArrNB for PRIM_IO.nullRd.  A null-reader never blocks 
(and never has any input), so readArrNB always returns SOME 0.

basis-library/posix/io.sml:322:
                fun noBlockWrap f x =
                   (ensureOpen ();
                    if !blocking then blockingOff () else ();
                    (SOME (f x)
                     handle (e as PosixError.SysErr (_, SOME cause)) =>
                        if cause = PosixError.again then NONE else raise e))
...
                    readArrNB = SOME (noBlockWrap readArr),
This is the readArrNB that gets created from the read system call (used by 
the readArr function).  Here, we turn off blocking before making the 
system call, then handle the errno=EAGAIN situation (i.e., reading would 
block) by returning NONE.