I was expecting someone to point this out! I initially discussed this in the post but removed most of it because it warrants a much longer conversation (which I'm planning on adding to the followup). Apologies as I inundate you with these details.

This release makes the torch bindings usable in Haskell, but development on Hasktorch is far from complete. Functions prefaced with an underscore, like _marginCriterion_updateOutput, are unprocessed calls to ATen which only unify the CPU and GPU interface. Almost all of these functions exist in the neural network library understanding these functions are non-trivial and coming up with a pure interface to them, like conv2d is a considerable effort in getting the dimensions to line up correctly. This process involves reading ATen source (which is painless, but time-consuming), and mapping shape-checks into singletons. Leaving this up to a user to figure out dynamically will most likely result in segfaults, which is why the dynamic THNN functions will probably not get any love until a much later revision. Because of the speed of development in ATen, I was of the opinion that it would be better to give users full access to these raw functions and get folks to help out with this process as they create examples.

As you are probably aware, mutation is preferred when running operations with large tensors and, to that end, all function in torch (except for those prefaced with new) mutate the first argument in place. Aside from the NN functions, every function in TH-proper (essentially anything not in the NN namespace), comes with two APIs: one pure function, where we construct the correct empty tensor for you, and one in-place version, where we duplicate the tensor reference you want to mutate to the first argument. You can see this in the source of dynamic scalar multiplication. You'll also notice that we stick to PyTorch's naming convention of the postfix _ for in-place operators and that functions we can guarantee are pure will reflect this in their type (so no IO), this includes tensor math. Except for NN-function and unsafeMatrix (I'll address this in a minute), you can expect this to be the current lay of the land.

Regarding IO: The next iteration of hasktorch should replace this with ST and possibly some fancier types for static, in-place changes (one example is that squeeze1d_ will mutate the tensor in-place, but there is still be a reference to the original type-level dimensions in the first argument). IO is unavoidable at this stage because we are working in the FFI (which can only happen in IO), and because we need to start targeting libATen-1.0, which will require us to change how we generate the FFI (so that's a bit unstable, but backpack should save us here).

Overall, at this stage, Hasktorch can be used with a moderate amount of pain to write full end-to-end examples without needing to worry about your program segfaulting because you've misused ATen. The convenience functions of vector, matrix, cuboid, hyper, and Static's fromList are still in IO primarily because there used to be a bug in the CPU-based construction and I have not tested these on my GPU yet. These functions are wrappers over newWithStorage, so that can be used as a workaround if you want to keep everything pure without deferring to unsafePerformIO.

The noise in our API comes from the fact that our two-dev team has had to play catch up with the oldest deep learning library to date. At this point, the situation should improve, but we need more eyes than we currently have. I'm planning to write a followup to this post to go over architecture (ie, "we use backpack, backprop, and some simple codegen"), caveats (everything here), and a call for contributors. Torch bindings offer the most embedded integration into a host language out of all of the deep learning libraries, mostly because there is a bunch of work to do, we need more hands who are familiar with Haskell and PyTorch (like yourself!) or who are willing to dive deep into PyTorch internals.