WIP - Work In Progress - WIP (well, on pause for now ...).
This project contains "Native" (JS) code and is to be viewed as a Web API exploration for elm, not as "a piece of Native code you can use in production".
Native (JS) code is going away in 0.19 so I emphasize again, do not use this for production code. To have more info about Native, Web APIs experimentations, or collaboration for the elm language, checkout the following links:
- (post) Richard Feldman, Building Trust: What Has Worked
- (post) Evan Czaplicki, What is "constructive" input?
- (post) Evan Czaplicki, "Native Code" in 0.19
A global summary of the exploration is presented in this blog post on the elm discourse.
This library aims at providing the
JavaScript TypedArray
API in elm.
My reasons are two-fold:
- Grow the cover of Web API in elm. Typed arrays are use for ArrayBuffers, Blobs, Files, network exchange, canvas data etc. So having them in elm is important in my opinion.
- They are the only fixed-size, typed structures in JS. Due to this, I'm convinced they can be used as a solid ground for fixed size efficient mathematical (Linear Algebra) library.
- cover full
TypedArray
API (except few bits that don't make sense in elm) - be elm compliant:
- appear as immutable data structure: modification create copies
- type safe polymorphism: add phantom types
- be interoperable with elm data structures:
- from elm data structures:
fromList
,fromArray
- to elm data structures:
toList
,toArray
- from elm data structures:
- be interoperable with JavaScript: 0-cost encoders / decoders
- be as minimalist as possible. It aims to follow the successful approach
of Skinney/elm-array-exploration which splits its array implementation in two parts.
First a minimal wrapper of JavaScript array in native code (
Native/JsArray.js
andArray/JsArray.elm
), and second, a pure elm implementation on top of it (Array/Hamt.elm
). - be flexible yet efficient:
- most functions are benchmarked and optimized
- most functions are also provided in an "indexed" form
- some functions have an "unsafe" form to avoid overcost of functor type returned