Nadrieril
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...