stackage VS purescript-halogen

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/

There's a framework in purescript from which u can grab some ideas I think: https://github.com/purescript-halogen/purescript-halogen.

If you wanna do web frontends right now, I'd recommend Halogen for Purescript since it is maintained and has documentation.

Before 2012, all of my websites were made using HTML, CSS and a sprinkling of JS. Then, I went all-in on AngularJS, followed by React. I started using Typescript and then PureScript and learned more frameworks like Halogen and Concur. I even wrote my own UI framework called purescript-deku.

First of all I had to choose what to use to manage the User Interface. I narrowed down to two modules: Halogen and react-basic-hooks (which is a “wrapper” of the unmaintained react-basic). I decided to go with react-basic-hooks just because I work with React on a daily basis and I wanted to understand its interoperability with PureScript. I will 10/10 try Halogen too in the next future since as far as I can see is the most famous and maintained in the PureScript community.

There's also Purescript, which is sort of a Haskell for frontend. It has type classes, HKTs and so on and also has a very nice FFI. When it comes to UI libraries there is Halogen which I think is very well though out and allows for using tagless final approach. There's also react-basic but I haven't used that one myself.

My favorite webapp stack at the moment is Halogen (PureScript UI library); I have always gravitated toward functional programming and strong static typing. For commercial work, however, I use React. While it isn’t perfect it strikes, for me, the right balance of purity, composability, and simplicity.

Yeah? I wrote something to deal with it too (https://github.com/toastal/return-optics) 5.5 years ago. You arguably chose the wrong data as `(model, Cmd msg, Maybe extMsg)` instead of `(model, Cmd msg, List extMsg)` which would give you more flexibility and still functions as a monoid on [] instead of Nothing, but allows multiple messages shrug. I tried this approach more recently and it involved me having to encode all of actions in a massive tree and then I still had issues with certain messages including now having to UUID all elements that that previously I didn't need to think about. It was a mess, but the best I could do with the tools at hand.

If you compare this to Halogen (https://github.com/purescript-halogen/purescript-halogen/blo...) where you still have purity but can set up subscribers and listeners from any component. It's much easier to use and for some components like dialogs, it's much simpler. And this actually isn't the best example because with the latest Halogen, Portals (https://github.com/purescript-halogen/purescript-halogen/pul...) was introduced so you can launch a dialog on the spot instead of even needing to communicate between them at all.

Below you can find the example of a simple button component written in Halogen: