[MLton-devel] basis-2002: IO

[Matthew Fluet]

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

Depends.  Right now, the BinOrTextIO functor doesn't produce half of the
required functions in the STREAM_IO signature.

Looking back at the BinOrTextIO functor, I see that it's very similar to
what is done in the PolyML sources.  That is, use an imperative buffer,
but if getInstream is called on the instream, turn it into a
StreamIO.instream.  We ought to be able to do the same thing here, but
building on the StreamIO functor to get the remaining functions.
Unfortunately, my StreamIO isn't as fast as the StreamIO produced by the
BinOrTextIO functor.  I agree that it's probably impossible to get the
imperative-on-stream as fast as a native imperative.

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

I don't think we can:

There are two structures matching the CHAR signature. The Char structure
provides the extended ASCII 8-bit character set and locale-independent
operations on them. For this structure, Char.maxOrd = 255.

The optional WideChar structure defines wide characters, which are
represented by a fixed number of 8-bit words (bytes). If the WideChar
structure is provided, it is distinct from the Char structure.


This is probably archaism in the Basis spec, but Char.char needs to be an
8 bit entity.  So, I don't think 


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

Again, it depends on what "level" of backwards compatibility we're looking
for.  I could (easily) create a BASIS_1997 signature and a Basis1997
structure that opens Basis2002 and wraps functions whose types have
changed (Array and Vector functions, OS.FileSys.readDir, etc.)  That
should allow most programs to type-check and compile, but it won't take
care of functions whose semantics have changed.  Likewise, we won't be
able to recover the non-opaque signature matches.  The major semantic
change that I've noticed is that Time.time admits negative values, so
Time.- doesn't raise Time as often as it did before.  (In particular, all
our problems with Time.now () going backwards wouldn't raise an exception,
although we'd get strange results.)



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