Primitives in Mlton

[bikallem]

I am implementing Buffer structure as defined here https://github.com/SMLFamily/BasisLibrary/blob/master/Code/2015/004/Buffer.sml.

Does mlton already provide the required primitives in lieu of these functions that I can use?

 prim_val create_ : int -> string                 = 1 "create_string";
    prim_val update_ : string -> int -> char -> unit = 3 "set_nth_char";
    prim_val blit_   : string -> int -> string -> int -> int -> unit 
                                                     = 5 "blit_string";

[MatthewFluet]

I don't think that you need primitives at all to implement structure Buffer : BUFFER. Strictly speaking, string is an immutable data structure as provided by the SML Basis Library (and MLton optimizes accordingly).

The linked file includes a "pure" SML implementation:
https://github.com/SMLFamily/BasisLibrary/blob/master/Code/2015/004/Buffer.sml#L73
which ought to be sufficient for MLton.

If you really wanted additional efficiency, then Unsafe.CharArray.create: int -> array omits both the Size check and does not initialize the elements (which is perfectly safe for a character array that has no pointers to be traced by GC) and Unsafe.CharArray.update : array * int * char -> unit omits the Subscript check. The blit_ operation is provided by CharArray.copy or CharArray.copyVec or the CharArraySlice variants (depending on the elements to be copied), though those would have bounds checks. One thing that MLton uses internally in the implementation of the Basis Library, but does not (currently) export via Unsafe is an operation to "cast" an array to a vector; this can be used to initialize the contents of an array (using update functions) and then "freeze" it as an immutable vector (with the safety requirement that the can be no uses of that memory as an array after this operation). But, MLton's implementation of CharArraySlice.vector will do that behind the scenes.

[bikallem]

Thanks. Is there any advantage/benefit in using Word8Array/Word8ArraySlice as opposed to CharArray? in terms of efficiency?

The blit_ operation is provided by CharArray.copy or CharArray.copyVec or the CharArraySlice variants (depending on the elements to be copied), though those would have bounds checks.

Indeed, I was wondering, does MLton already have unsafe versions of the above specific functions as primitives? If so can I perhaps peruse it? This is useful for performance since most of the Buffer functions already do check bounds and additional bounds check by the Basis lib seems a bit wasteful.

[MatthewFluet]

Thanks. Is there any advantage/benefit in using Word8Array/Word8ArraySlice as opposed to CharArray? in terms of efficiency?

None at all in MLton. After front-end type checking, Word8.word and Char.char are the same type.

The blit_ operation is provided by CharArray.copy or CharArray.copyVec or the CharArraySlice variants (depending on the elements to be copied), though those would have bounds checks.

Indeed, I was wondering, does MLton already have unsafe versions of the above specific functions as primitives? If so can I perhaps peruse it? This is useful for performance since most of the Buffer functions already do check bounds and additional bounds check by the Basis lib seems a bit wasteful.

Yes; see copyArray and copyVec from:
https://github.com/MLton/mlton/blob/master/basis-library/primitive/prim-seq.sml

But, they are not exported by structure Unsafe, so to use them, you would need to implement "inside" the Basis Library.

In general, there are multiple dimensions along which sequence (array and vector) operations can be unsafe. In addition to bounds checking, there is the difference between SeqIndex.int (the integer type used for native indexing of sequences, Int64 on 64-bit systems and Int32 on 32-bit systems) and Int.int (the "default" integer type, typically Int32 on all systems, but user-configurable with -default-type); when SeqIndex.int and Int.int are different types, then there is also some checking when converting between them (and to ensure that we raise Size rather then Overflow).