Philip Potter

Apologies for double-post, but a further thought occurred to me: I wonder if we could mildly simplify the language if we were able to define JSON (and List) as special-cased...

I don’t really agree with this analysis. I think caching with content-derived cache keys (the current implementation) is a really nice spot in the design space to occupy. I don’t...

I think my default starting point for an extra caching mechanism is “just use http” - Cache-control, Expires and Etag headers. That way there’s a bunch of prior art and...

Opinion: it should be in `$XDG_CONFIG_HOME` somewhere, such as `~/.config/dhall-haskell.dhall`. We already use the XDG spec to define where the cache goes. EDIT: thing in a more cross-platform way, we...

It should be `XDG_CONFIG_HOME`, not `XDG_CACHE_HOME`. But I’m actually having second thoughts. The thread is taking about loading the first config file it finds, but that would be highly surprising...

I’m a weak +1 to this idea. I agree that error messages are really important and I think standardising on them is a good idea. Dhall-golang has literally copypasted a...

@x448 no there isn’t. That’s why this is an issue on dhall-lang and not on fxabacker/cbor.

I can’t speak for non-Go implementations (this repo is for the Dhall language standard, not for any specific implementation) but ugorji/go/codec’s "Canonical" setting sorts by "natural sort order" before encoding,...

> @philandstuff: Wouldn't this be a highly breaking change to hashes? My understanding is that almost all Dhall packages would likely be at risk of hash disruption This affects any...

@Nadrieril my guess (without trying) is that it takes the Go builtin sort order for maps, which is deliberately random and not consistent between invocations. That said, I've thought of...