Simon Jakobi

> @kukimik: This is more specifically an issue with the Haskell implementation of Dhall. See: [dhall-lang/dhall-haskell#2200](https://github.com/dhall-lang/dhall-haskell/issues/2200) https://github.com/dhall-lang/dhall-haskell/issues/1592 has a bit more discussion on the technical background and how it could...

Just for completeness, there's another way to define long strings: ```dhall Prelude.Text.concat [ "Some long " , "text" ] ``` IMHO strings are already a rather complex part of the...

> As a note, it would be pretty painless to add octal literals because they are currently a syntax error: #898 @philandstuff Is this an argument to use `0` for...

Interestingly, even YAML has moved to using the `0o` prefix in v1.2. Currently, I feel that a minor speedbump is acceptable, if it helps make the notation more readable and...

I've just made a pass over `dhall`'s current direct dependencies. If we'd move the `Dhall` module and its module dependencies into a new library package, I expect that the new...

> * Regarding 'profunctors': I'd say lets revive [Eventual fate of the Dhall.Optics module #998](https://github.com/dhall-lang/dhall-haskell/issues/998) and try to remove that dependency there. Maybe I'll get to it next week. I'm...

> However, I think I will go with the approach that @MonoidMusician suggested (to parametrize the expression type on the key-value type constructor), since I will need to do that...

I believe that the departure from the existing Dhall-JSON-YAML pipeline discussed in https://github.com/dhall-lang/dhall-haskell/issues/1435 could help us preserve the order of fields when translating Dhall to YAML.

> In all cases, this could simply desugar to multiple `let` bindings; no need for any other changes to the language. Can you explain the desugaring in some more detail,...

I think this has the potential to create some confusing error messages. Say you start with ```dhall expose Prelude.List in map … ``` Then you add another `expose` ```dhall expose...