[MLton-user] Raw conversion of 32 bits into Real32.t

Stephen Weeks sweeks at sweeks.com
Mon Jan 22 18:36:15 PST 2007


I don't see the use of One as massive overkill, and I'm not even sure
it's overkill.  Let's compare the client code.  Here is Wesley's:

  fun convert w = let
     val a = Word8Array.tabulate (4, fn _ => 0wx0)	
     val () = PackWord32Little.update (a, 0, w)
  in
     PackReal32Little.subArr (a, 0)
  end

And here is a version defined using "withOne":

  val convert =
     withOne
     (fn () => Word8Array.tabulate (4, fn _ => 0wx0),
      fn (a, w) => let
         val () = PackWord32Little.update (a, 0, w)
         val r = PackReal32Little.subArr (a, 0)
      in
         r
      end)

where withOne is a generally useful function defined as follows:

   fun withOne (f, g) = let
      val z = One.make f
   in
      fn b => One.use (z, fn a => g (a, b))
   end

So, I don't see much difference between the two "convert" functions,
except that the "withOne" one has taken care to express the fact that
the array should be local to each call to convert.  While Wesley's
certainly expresses the same fact, it is not explicit, and so could be
intentional or not.  Also, by not being explicit it loses the chance
for the programmer to optimize things by using different
implementations of One.

Note that a perfectly valid implementation of One is :

  structure One: ONE = struct
     datatype 'a t = T of unit -> 'a
     val make = T
     fun use (T f, g) = g (f ())
  end

That implementation yields beta-equivalent code to Wesley's, so if
MLton does ever optimize things away, then we can use it.  In the
meantime, we can use the atomicBegin implementation of One, or the
test-and-set version once we have a test-and-set primitive.  The
atomicBegin is clearly only doing a test-and-set, as we discussed when
we first came up with One.  That should be very cheap.

As to the cost of the array creation, it can be relatively high if the
rest of the code is simple, as it is in this case.  So not using One
will hurt.

One other point -- MLton should eventually have a primitive for
directly doing this conversion, eliminating the need to use an array
entirely.



More information about the MLton-user mailing list