[MLton-devel] basis-2002: IO

[Stephen Weeks]

> 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.

Yeah.  Is there anything in the spec that prevents us from moving
forward by using the old fast implementation of BinIO and TextIO while
keeping around the new lowlevel stuff?  I'm not convinced that even
with a lot of effort you can get the imperative-layered-on-functional
approach to be as fast as the current imperative approach.  And I'm
not sure it's worth the time to figure out, since we've never missed
the missing stuff and have never heard from any user that misses it
either.

> 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.

BinOrTextIO implements a buffer management scheme directly on top of
Posix.IO.  It uses an imperative approach, keeping a single array of
elements per stream that is mutated as characters are read.  The
functorization is only there for dealing with the different types of
vectors and elements that BinIO and TextIO deal with and so we can
pass different flags to open on Windows for binary files.

> A sort side question -- but is there any reason not to make char and
> Word8.word the same?

I don't think we should do this.  Some day, we may want to switch to
unicode chars, which will take 16 (or maybe even 32) bits.

As to switching to the new library, since we just did a release, now
is as good a time as any.  However, I still think it would be a good
idea to have a compatibility switch for the old library, accessed with

	-basis-library {2002|1997|none}

I think the right way to do this is to have parallel signatures
(BASIS_1997, BASIS_2002) and structures (Basis1997, Basis2002), and
parallel build-basis files, which can then be switched between at
compile time (in compile.sml).  Do you have any thoughts on how hard
it would be to create these?  I am hesitant to transition until we
have some backwards compatibility.


-------------------------------------------------------
This sf.net email is sponsored by: viaVerio will pay you up to
$1,000 for every account that you consolidate with us.
http://ad.doubleclick.net/clk;4749864;7604308;v?
http://www.viaverio.com/consolidator/osdn.cfm
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel