Profpatsch

Also errors like `PrettyHttpException` don’t carry a source code position even though they totally could.

I’m afraid I don’t have time to deep-dive at the moment (it’s a rather fundamental change of the main functions), I just wanted to bump the topic to mark interest.

I notice that the pretty-printed error message contains an import chain, though I’m not sure where it gets it from. It’s not in the errors that are thrown by `Import.loadWith`....

For reference, this is how I catch errors at the moment: https://github.com/Profpatsch/dhall-flycheck/blob/3d11abbebf80eef2df98ce90d92f9453a0309637/src/Dhall/Flycheck.hs#L256-L294 Note that this list has to be kept in sync with the actual (open) error list on every...

> Would that work? It would solve the problem of not being forced to be exhaustive, yes, but not the problem of having no good error positions for most of...

> The reason the standard requires support for deserialization is because in the extreme case the user can do this: > > ```haskell > missing sha256:… > ``` Should we...

Ah, true. But we should have it as an explicit invariant and add a `--verify` to `dhall freeze` (so people can e.g. check on CI). “You can do that, but...

> Relying on cache state is very brittle. A file might work on one computer and break on computer because the prelude changed in the meantime. It doesn't make sense...

> As another data point, I use hashes more for integrity checks as explained here: http://www.haskellforall.com/2017/11/semantic-integrity-checks-are-next.html#refactoring. The caching is the icing, for me. Good icing, but icing nonetheless. Also full...

Heh, I *knew* I’d seen something. I even commented. :D