gabby

@mmhat: I think the main reason I'd prefer quotations instead of a `base16:` prefix is that if we add other types of numeric literal notations then we can also turn...

Also, I just realized a reason why a `bytes : Natural → Bytes` built-in wouldn't work, because we'd have no way to represent `Bytes` with leading zeros, because `0x00FF` from...

@JohannesRudolph: The main issue here is that the conversion to YAML is conceptually done in two steps: * Evaluate the Dhall expression to its normal form * Convert that normal...

@f-f: That won't work in general because the records might be computed and might not be present in their entirety in the original syntax tree parsed from the file. For...

@antislava: The main thing that makes it tricky is the API's support for custom normalizers. You'd have to thread the sorting decision throughout the code in a lot of places....

I'm going to move this issue to the `dhall-haskell` repository since it's specific to the Haskell implementation

We don't have an official roadmap. It's mainly whenever one of us can get around to this Part of the delay is that this particular change requires pretty sweeping changes...

@SiriusStarr: Normally, I would be mildly against supporting "open" imports, but when I saw that you could combine it with record projection to create explicit imports: ```dhall let Prelude =...

@ari-becker: I don't believe that @SiriusStarr is proposing that an imported record can refer to variables in scope at the point of the `expose` keyword. My understanding of this proposal...

@sjakobi: I no longer think the absence of exhaustivity checking is a requirement for destructuring records. Specifically, what convinced me is the implementation of closed imports in terms of open...