stack VS yesod-persistent

Ah, didn't run into this issue, as I don't use vscode.

Apparently there is some work being done to improve the stack <> hls experience, but I wouldn't know how it's going and when it's being delivered: https://github.com/commercialhaskell/stack/issues/6154

this is it: # This file was automatically generated by 'stack init' # # Some commonly used options have been documented as comments in this file. # For advanced use and comprehensive documentation of the format, please see: # https://docs.haskellstack.org/en/stable/yaml\_configuration/ # Resolver to choose a 'specific' stackage snapshot or a compiler version. # A snapshot resolver dictates the compiler version and the set of packages # to be used for project dependencies. For example: # # resolver: lts-3.5 # resolver: nightly-2015-09-21 # resolver: ghc-7.10.2 # # The location of a snapshot can be provided as a file or url. Stack assumes # a snapshot provided as a file might change, whereas a url resource does not. # # resolver: ./custom-snapshot.yaml # resolver: https://example.com/snapshots/2018-01-01.yaml resolver: url: https://raw.githubusercontent.com/commercialhaskell/stackage-snapshots/master/lts/20/23.yaml # User packages to be built. # Various formats can be used as shown in the example below. # # packages: # - some-directory # - https://example.com/foo/bar/baz-0.0.2.tar.gz # subdirs: # - auto-update # - wai packages: - xmonad - xmonad-contrib # Dependency packages to be pulled from upstream that are not in the resolver. # These entries can reference officially published versions as well as # forks / in-progress versions pinned to a git hash. For example: # # extra-deps: # - acme-missiles-0.3 # - git: https://github.com/commercialhaskell/stack.git # commit: e7b331f14bcffb8367cd58fbfc8b40ec7642100a # # extra-deps: [] # Override default flag values for local packages and extra-deps # flags: {} # Extra package databases containing global packages # extra-package-dbs: [] # Control whether we use the GHC we find on the path # system-ghc: true # # Require a specific version of Stack, using version ranges # require-stack-version: -any # Default # require-stack-version: ">=2.11" # # Override the architecture used by Stack, especially useful on Windows # arch: i386 # arch: x86_64 # # Extra directories used by Stack for building # extra-include-dirs: [/path/to/dir] # extra-lib-dirs: [/path/to/dir] # # Allow a newer minor version of GHC than the snapshot specifies # compiler-check: newer-minor

Fix incorrect warning if allow-newer-deps are specified but allow-newer is false. See #6068.

You can download binaries for this pre-release from: Release rc/v2.11.0.1 (release candidate) · commercialhaskell/stack · GitHub .

Fair enough! Thanks for the suggestion, then. In fact, the non-Python language I develop most in (Haskell, with the Stack package manager) has exactly that behaviour as a default: new packages are installed to a sandboxed local directory, and it takes an explicit request to install something globally. (And even then, you can switch between different global "known good configurations" of package versions which work well together – a pretty handy feature.)

Opened a ticket on GitHub.

In YAML configuration files, the hackage-security key of the package-index key or the package-indices item can be omitted, and the Hackage Security configuration for the item will default to that for the official Hackage server. See #5870.

FYI this was solved in here: https://github.com/commercialhaskell/stack/issues/5958

Yes, that is correct. Stack's allow-newer: true configuration has always actually meant 'ignore bounds'. However, the author of the allow-newer-deps development has in mind a further development that will introduce an actual ignore-bounds key with the same expressive syntax that is used by Cabal. This is discussed at Stack #5910.

I also looked into Snap (http://snapframework.com/) and Yesod (https://www.yesodweb.com/) for Haskell. I didn't really get anywhere with those though because I had build issues with dependencies and was in a bit of a hurry so I put them off for later.

If you have a yesod app and want to try this out, I've got a cabal.project that works for yesod and persistent: https://github.com/yesodweb/yesod/pull/1769

It would be an unorthodox choice. If you're looking to use this personal site as a portfolio project, you'd probably be better off using something like Node (JS), Java, or Python which tend to be a bit more marketable. However, if you want to try learning Haskell, then building a personal site with it seems like a great way to dive in. If you want to learn a bit more, Yesod seems to be the most well-documented Haskell web framework

I believe yesod is the go-to all encompassing framework.

frameworks like yesod and IHP

In this blog post I’m presenting an implementation of a Wiki System in the spirit of the legendary C2-Wiki - written in Haskell with the Yesod framework.

I'm wondering if this is related to this.

> Every language phasing the web is stringly typed

Heh, not even close. Off the top of my head I can think of Ur/Web as an extreme example ( http://www.impredicative.com/ur ), and slightly more mainstream systems like Yesod ( https://www.yesodweb.com ). I've worked professionally with Haskell, although not for Web stuff. These days I mostly work with Scala, which has a similar typing mindset to ML/Haskell, but unfortunately inherits a lot of stringly typed legacy from Java. We use an in-house library that provides zero-cost newtypes to distinguish between different semantically-distinct data types, many of which just-so-happen to be representable as subsets of String (e.g. GET parameter names, GET parameter values, POST bodies, etc.). This makes it a type error to try and e.g. concatenate different sorts of data together.

W.r.t. "escaping", I tend to avoid it entirely since it's inherently unsafe:

- "Escaping" doesn't distinguish between its input and output types; they're both just "String", and we have to make assumptions about the contents of each (i.e. it's unsafe)

- Having the same input and output types makes it possible to "double-escape" by accident. This discourages the use of escaping, just-in-case it happens to be done elsewhere; hence it's very common to end up without any escaping taking place.

- Having the same input and output types makes escaping functionally unnecessary: anything we do to an escaped string could also be done to an unescaped string, so it's up to us to remember that it's needed (i.e. it's unsafe).

The whole idea of "escaping a string" betrays a flawed approach to the problem. Instead of throwing everything into the same representation, then manually trying to figure out whether or not a value comes from a particular subset of that representation or not, it's much easier and safer to avoid lumping them all together in the first place. If our inputs have a certain type (e.g. HTTP.Get.Val) and we can only output certain other types (e.g. JSON, Map[HTTP.Header.Key, HTTP.Header.Val], etc.), then the processing which turns input into output is forced to specify any necessary conversions. Whilst such conversions may involve escape sequences, having them associated to particular types is more akin to serialisation.

Heck, at my first PHP job we largely solved this problem not by 'filtering and escaping', but by modifying the PHP interpreter to distinguish between 'clean' and 'dirty' strings (with literals being clean, and $_GET, etc. being dirty). Operations like concatenation would propagate 'dirtiness', and output functions like 'echo' would crash if given a dirty string. Traditional 'escaping' functions would convert dirty strings to clean ones, and crash when given a clean string. Having this be dynamic was more annoying than ahead-of-time compile errors, but it still did a pretty good job.

There's pretty much no excuse for stringly typed languages/libraries/etc. when such such trivial solutions exist, other than the historical inertia of legacy systems.

The project is going to make use of Warp. To smoothen the development process I set up yesod-bin according to their template for non-yesod projects. This worked fine initially, giving me hot reloading on file changes, but after adding the private package as described above it's giving the following error: