stackage VS accelerate

Writing Haskell programs that rely on third-party packages is still an issue when it’s a not actively maintained package. They get out of date with the base library (Haskell’s standard library), and you might see yourself in a situation where you need to downgrade to an older version. This is not exclusive to Haskell, but it happens more often than I’d like to assume. However, if you only rely on known well-maintained libraries/frameworks such as Aeson, Squeleto, Yesod, and Parsec, to name a few, it’s unlikely you will face troubles at all, you just need to be more mindful of what you add as a dependency. There’s stackage.org now, a repository that works with Stack, providing a set of packages that are proven to work well together and help us to have reproducible builds in a more manageable way—not the solution for all the cases but it’s good to have it as an option.

> That is fine, as far as it goes, but obviously this will, at some point, be at odds with the interests of programmers looking to use Haskell as a practical, stable tool.

That's what Stackage is.

Stackage provides consistent sets of Haskell packages, known to build together and pass their tests before becoming Stackage Nightly snapshots and LTS (Long Term Support) releases. [1]

Java will never get this.

[1] https://www.stackage.org/

makefile_dir := $(dir $(abspath $(lastword $(MAKEFILE_LIST)))) export PATH := $(makefile_dir):$(PATH) project_name ?= project_main ?= src/.hs retag_file ?= $(project_main) stack.yaml: @test -f stack.yaml || (echo -e "This makefile requires a 'stack.yaml' for your project.\nYou don't need to use 'stack' to build your project.\nYou just need a 'stack.yaml' specifying a resolver compatible with your GHC version.\nSee https://www.stackage.org/" && exit 1) stack: stack.yaml @which stack || (echo -e "This makefile requires 'stack' to be on your path. Use GHCup to install it.\nSee https://www.haskell.org/ghcup/" && exit 1) .PHONY: stack warning.txt: -@uname -a | grep -q Darwin && echo "WARNING: On Mac, you must alias 'make' to 'gmake' in your shell config file (e.g. ~/.bashrc or ~/.zshrc). Symbolic links will not work." | tee warning.txt @echo "Add 'warning.txt' to your .gitignore file if you never want to see this message again." hasktags: warning.txt stack @echo 'stack exec -- hasktags' > hasktags @chmod +x hasktags @echo "You might like to add 'hasktags' to your .gitignore file." format: stack @stack exec -- fourmolu --stdin-input-file $(project_main) .PHONY: format retag: warning.txt stack @stack exec -- haskdogs -i $(retag_file) --hasktags-args "-x -c -a" | sort -u -o tags tags .PHONY: retag tags: warning.txt hasktags stack @stack exec -- haskdogs .PHONY: tags ghcid: stack @stack exec -- ghcid \ --command 'stack repl --ghc-options "-fno-code -fno-break-on-exception -fno-break-on-error -v1 -ferror-spans -j"' \ --restart stack.yaml \ --restart $(project_name).cabal \ --warnings \ --outputfile ./ghcid.txt .PHONY: ghcid

(why lts-18.28? it's the latest 8.10 release on https://www.stackage.org/ )

I don't see way community maintenance can change the GHC for nightly.

It makes total sense that it fails since at no point I requested that the library be installed, which makes me wonder: Is there any way to request Hackage to install SDL and GLEW before attempting the build? I see Stackage has debian-bootstrap.sh. Does something similar exist for Hackage?

At this point, you can try a Stack snapshot that uses an older version of GHC. Looking at Stackage, you can see that the latest version before 8.10.* is 8.8.4 (using LTS 16.31). Starting over with that snapshot, you find that the packages that you need are in the snapshot and work.

On the contrary, I think this is standard practice for packages which are part of stackage. When stackage nightly switches to a new version of ghc, all the packages which are incompatible with the new ghc are dropped from nightly. My understanding is that maintainers are then expected to fix their packages, at which point more and more packages are included in the nightly snapshot. The next lts to include that version of ghc is only released later, once most packages have been added back, so unlike ghc users who diligently upgrade to the latest ghc, stackage users who diligently upgrade the latest lts snapshot shouldn't see a big drop in the number of compatible packages.

I found the latest stack lts version, and it's associated ghc version here: https://www.stackage.org/

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.