Nadrieril

Since we currently disallow line breaks within double-quoted string literals, I thought we could actually allow them and just ignore them. And strip indent as well. Problem is, then ```dhall...

That... seems like a terrible can of worms, when baking JSON/YAML parsing in implementations would be rather easy and justified by our current goal of displacing yaml. I expect many...

Actually, the issue of escaping strings when generating output in a particular format does come up regularly. For me that's an argument for allowing Text manipulation always.

Ah, new idea: if we want custom parsers, they will need to generate data of a type that depends on the input. They might also need to take as input...

> Not necessarily. We could preserve the spirit of this proposal (_i.e._, pushing the text manipulation to the edges of the system) by extending the use of `as` or similar...

@Gabriel439 I mean that's like any other software engineering problem. In Haskell or Rust, libraries could use strings instead of sum types too, but no serious code does. I don't...

Note that the recent precedence change of `with` (https://github.com/dhall-lang/dhall-lang/pull/954) also has that problem

I'm confused: wouldn't ```dhall ... , mode = "0644" ... ``` give the correct YAML output? And wouldn't an octal numeral be output as a completely different decimal number? Otherwise...

> @Nadrieril: For YAML specifically it wouldn't require any changes to the Haskell implementation's AST to keep track of octal. We already preserve the original source code for numeric literals...

> What if we enforced the "at most one open import" rule at the language level? That would prevent a lot of legitimate uses for a nested open import local...