Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
JohnReppy opened this issue May 10, 2018 · 6 comments
Open

Comments

@JohnReppy
Copy link
Contributor

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

ratmice commented May 11, 2018

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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

ratmice commented May 17, 2018

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

@JohnReppy
Copy link
Contributor Author

Damn autocorrect

@eduardoleon
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants