Discussion for proposal 2018-001 (Addition of monomorphic buffers)

[JohnReppy]

This issue is for discussion of proposal 2018-001 (Addition of monomorphic buffers).

Note that this proposal is a generalization of the earlier proposal 2015-004.

[ratmice]

Nifty, having not quite thought through the details of an efficient implementation, Just one minor thought

the only thing I wonder about is if this doesn't warrant the addition of a Buffer.intoArray{src, dst, di} function, similar to the Array.copyVec one,

in the sample implementation to go from Buf -> Array, it appears you need call Array.copyVec{src=Buffer.contents(buf),dest=arr,di=0} With the Buffer being backed by an array, induces a copy from Array -> Vector -> Array, Where intoArray could just call Array.copy.

I imagine in an efficient implementation does not induce the interim copy in Buf.contents(buf), so it seems to me its inclusion would primarily be for some gained efficiency on implementations such as the sample one.

[JohnReppy]

I agree that a copy-to-array operation would probably be a useful addition (and there is a definite performance benefit to making it a primitive). It might also be useful to provide a buffer-append operation.

[JohnReppy]

I have updated the proposal with a copy function (suggested above) and a sub function for accessing buffer elements. The other operations that I think might be useful to include are: addBuf for appending the contents of a buffer, and app and fold combinators for iterating over the contents of a buffer.

[ratmice]

:+1: I Fixed a small typo in the type of the copy function, s/src : but/src : buf/

[JohnReppy]

Damn autocorrect

[eduardoleon]

Using buffers as a tool for constructing large immutable vectors (of which strings are a particular case) makes perfect sense. However, it is not clear to me what we gain by having both growable buffers and fixed-size mutable arrays. Would it not be simpler to add resizing operations to the existing array types? C++'s std::vector and Python's list are a lot more useful than SML's ARRAY or MONO_ARRAY signatures, precisely because the former do not require the user to predict the final size of their array.

On an unrelated matter, for simple enough element types (basically, SML counterparts to C's built-in integer and floating point types), it would be useful to have a standardized unsafe function that returns a pointer to the first element in a monomorphic array. Such pointers can then be passed as arguments to external functions, presumably implemented in low-level languages such as C and Fortran. For example, in this way one can write portable bindings to numerical algebra libraries.