Fabrizio Ferrai

This reminds me of an idea that @phadej had [in this tweet](https://twitter.com/phadej/status/1042494262858997760), that is to have a Haddock for Dhall. I think the "distribution method for the Prelude" (which IMO...

I'd be with @Profpatsch here, in the sense that I think more builtins are convenient (e.g. both this proposal and datetimes from #80 make sense to me), but adding more...

Googling around about this I read that passing `-split-objs` to GHC [might help](https://stackoverflow.com/questions/9198112/haskell-unnecessary-binary-growth-with-module-imports/9198223#9198223)

@JohannesRudolph at work we went through exactly the same "brownfield" process that you described. To keep the configs "auditable" and "debuggable" we just print the rendered YAML/JSON/etc to the CI...

> #74 makes errors like this one easier to debug since all bindings are explicit. So maybe we could make the projection obligatory? Yeah I would also say that we...

Yeah thinking more about it, allowing one and only one open import sounds sensible. Though I think the check (and eventual rejection of the program) should be performed at the...

@SiriusStarr: the problem with optional/not-enforced things is that they end up being ignored. A very good example of this in my experience is "optional typing": if it's not enforced by...

Meta-note, quoting from https://github.com/dhall-lang/dhall-lang/issues/260#issuecomment-433992627: > In the interest of avoiding hostility I'm going to ask that people refrain from using GitHub reactions (both positive and negative) to weigh in on...

@SiriusStarr I agree that the sequence of `let`s there doesn't look too good, and in fact this would be solved by #74 where you could write ```dhall let { a,...

I'm on board with what @sjakobi and @Nadrieril suggested, which is to try out #74 first and then see where to go from there