[MLton-devel] basis-2002: IO

[Matthew Fluet]

I've got a fairly complete "Required" Standard ML Basis Library working on
the basis-2002 branch.  The major missing functionality is the OS.IO.poll
type and related functions, TextIO.inputLine and TextIO.outputSubstring,
and attaching atExit closing of opened files.

So, there are now the required TextPrimIO and BinPrimIO structures with
associated reader and writers.  I went ahead and wrote versions of the
PrimIO, StreamIO, and ImperativeIO functors, which match the spec to the
best of my understanding -- there are quite a few unclear areas that I've
noted down; poking through the SML/NJ and Poly/ML source code shows a
couple of places where they've taken very different interpretations.

Anyways, I tried building up TextIO and BinIO from the primitive IO layer
using the functors.  And, was mostly successful, in that I can open and
close files, read and write to them, etc.  On the other hand, it's
probably a painfully naive buffer management scheme.  Using the default
4096 bufsize and TextIO.input and TextIO.output, the release and the
basis-2002 branch are about the same for reading in and writing out an 8M
file.  On the other hand, if I use TextIO.inputN 16, then the basis-2002
branch is about 20X slower.  Not a good sign.

I couldn't follow completely how the BinOrTextIO functor works.  Clearly,
it's not building up from primtive readers and writers, but the only thing
a reader and writer really does is mediate access to
Posix.IO.{read,write}{Vec,Arr}, and close.

A sort side question -- but is there any reason not to make char and
Word8.word the same?  As best I can make out, only the Byte structure
translates between the two, and all the associated primitives are identity
functions.  So, it seems that we can pull the same trick to make char and
Word8.word the same as I did to make CharVector.vector and String.string
the same.  The opaque signature match at the basis export will force code
outside the basis to respect the type distinction.  I mention this because
it really seems as though TextIO could be implemented directly as BinIO
with the signature cast performing the mask.

I know that it would complicate the front end a little and removing
Cases.Char from the compiler internals would need a little bit of clean
up.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel