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

[Wesley W. Terpstra]

On Jan 23, 2007, at 1:04 AM, Henry Cejtin wrote:
> The  problem  of the thread-safe aspect of allocation outside a  
> function call
> has   already   been   solved.    Look    at    the    structure     
> One    in
> basis-library/util/one.sml.
>
> The signature is
>
>     sig
>        type 'a t
>
>        val make: (unit -> 'a) -> 'a t
>        val use: 'a t * ('a -> 'b) -> 'b
>     end
>
> The  arg  to  make  is  the creation thunk.  A single copy is made  
> and saved,
> along with the thunk and a flag.
>
> When use is called, it checks if the single premade copy is in   
> use.   If  it
> isn't then it passes it to its second arg.  If it is then it makes  
> a new one.

This is all well and good for the situation where there is a high  
cost associated with the object creation. However, in Matthew's  
example, the method was so small and its scope so narrowly defined,  
that I think using 'One' is massively overkill.

I think my version (with the inline creation) should be preferable on  
the grounds of simplicity and thread-safety. If things really need to  
be optimized by the user, then your above solution is certainly  
appropriate.

> It is way better than having to re-allocate things every time.

Ok, I understand that the vector gets allocated on the heap. But the  
naive programmer in me says: this should have been allocated on the  
stack, ala alloca()!

In fact, that programmer is not so naive: Doesn't MLton have all the  
information it needs to realize that the array is allocated inside of  
function scope, not returned, and never needed by a closure?  
Therefore, it shouldn't be allocating it on the heap, but on the  
stack. I'd think that this would improve performance of a wide-range  
of methods, and make thread-safe code faster and simpler than  
Matthew's non-threadsafe example.