accelerate VS servant

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.

> do you really have to understand language extensions?

You do when your code doesn't compile and you're trying to figure out what the error message means, or when the library you want to use makes heavy use of it for even basic functionality.

> These days one just enables GHC2021

My experience was pre-GHC2021. I basically had to enable at a minimum 5-6 language extensions in every single file.

> Mostly they're just about removing unnecessary restrictions from the older standard.

Yeah, those ones are usually fine. I have zero objection to things like FlexibleInstances or DeriveFoldable.

> Could you give an example?

I believe I was trying to implement Central Authentication Service using Servant. However, that required returning a custom HTTP status code. There has been an open Github issue for this since 2017, but it seems to require basically rewriting the entire framework: https://github.com/haskell-servant/servant/issues/732

Looking back at it now Servant does have "ServerError", but that basically requires giving up all the advantages Servant claims to have and I believe it was not a viable option at the time. Looking at the timeline I was probably also on Servant 0.15, and there seems to have been a rewrite since then.

I vaguely recall running into a similar issue trying to interact with a database, but I can't remember the details of that.

a HasSwagger instance for NamedRoutes was added in May 2022 (in this commit) but there hasn't been a package release since March

If you don't like this style, the usual alternative is to change mkDualAuthHandler to take two additional arguments, Proxy tag0 and Proxy tag1 (as e.g. lots of Servant functions do, for historical reasons).

Dunno if this is helpful, but I found this github issue about ResourceT and servant https://github.com/haskell-servant/servant/issues/1345

And what about the cabal repl --with-compiler=doctest, which was added recently, in doctest v0.20? I recently submitted a PR for Servant to use this in place of GHC environment files, because it seems less finicky to me. Was this a bad idea?

I asked a somewhat relevant question recently. Maybe you'll find this discussion somewhat helpful: https://github.com/haskell-servant/servant/issues/1547; two packages were talked about. One of the folks from Well Typed replied, and said they tried it recently (and worked fine).

You are highly encouraged to test this release out and let us know what you think ! For bug reports, features requests or any kind of feedback, just open a ticket on our issue tracker.

Even slower than :<|> quadratic compile time in number of routes?

Check this out https://github.com/haskell-servant/servant/issues/335#issuecomment-172300487