accelerate VS polysemy

Someone has opened a PR for accelerate here https://github.com/AccelerateHS/accelerate/pull/525 (sadly seems not actively maintained at the moment, but that can always change if people care enough). I agree for an executable you should freeze your dependencies and compiler version, and using 8.10 is fine. Although there are tons of improvements in 9.2+

Backprop is a neat library. However, I guess its use case is if you actually don't want to go for anything standard like Torch or TF (perhaps for research?) For instance, if I were to use something like Accelerate for GPU acceleration, or some other computation-oriented library, then I would mix it with Backprop. Previously, I have benefited from Backprop in a ConvNet tutorial and I liked it.

Wait, really? Here's a conversation I had with him: https://github.com/AccelerateHS/accelerate/discussions/528

I know Accelerate is being developed at Utrecht University in the Netherlands. You can look at publications by Trevor McDonell to get a taste of what they are doing.

I’m personally a big fan of http://www.acceleratehs.org / https://github.com/AccelerateHS/accelerate-llvm

Looking for a few projects that make use of it, I found accelerate, hawk, polysemy and pretty-simple, so I'll be interested to poke around in their code and see how they have things set up.

There's accelerate for GPU computing and hmatrix for bindings to BLAS and LAPACK.

I'm toying with the idea of replacing vector values with vector generators, where e.g. v1 + v2 is not evaluated to a new vector, but to a vector program. This is similar to the approaches of Accelerate and TensorFlow. On the flip side, I don't think I could get rid of the overhead, and I expect much smaller computation loads than aforementioned libraries, so overheads could be very significant. The added benefit of using vector generators is that the generator could not only be evaluated, but also be turned into a Latex formula.

Thirdly, composing arbitrary effects without losing state is really, really difficult. Things are fine when you limit yourself to State and Reader, sure, but once you start with nondeterminism you’ll discover it’s shockingly easy to produce behaviors that are baffling unless you’ve spent a preposterous amount of time thinking about this stuff. (I’ve been bitten in prod by silent state-dropping bugs, and rarely have I been more flummoxed.) Consider this example, which produces silent changes in the semantics of <|> depending on whether you use it inside or outside of a higher-order effect. Every single effect library (besides the still-unreleased eff) gets certain combinations of effects + nondeterminism wrong. You could make the argument that most people don’t use nondeterministic monads, but eDSLs really shine when you have access to them, as you can turn a concrete interpreter to an abstract one fairly easily.

Looking for a few projects that make use of it, I found accelerate, hawk, polysemy and pretty-simple, so I'll be interested to poke around in their code and see how they have things set up.

Right, I think I'll just give it a shot to see. Polysemy is nice but I'm still having trouble getting what I want out of it (which may very well be entirely a fault of my own understanding)

Languages such as Koka only support algebraic effects, not scoping operations such as catch and listen. The Effect Handlers in Scope paper introduces scoping operations, which lead to the Haskell libraries fused-effects and polysemy, but they turned out to have some weird semantics. eff is her effort to fix that.

Looking at the interpreter for Reader might give some clues if this doesn't work. https://github.com/polysemy-research/polysemy/blob/master/src/Polysemy/Reader.hs#L38-L45

*But I'm not terribly well versed in Scala's other DI offerings. I came from Haskell and didn't find anything in Scala that clicked with me until I found ZIO. It reminded me a lot of my favorite way of writing Haskell programs (https://github.com/polysemy-research/polysemy)—albeit with a completely different implementation.