Stephen Paul Weber

I'm curious what the use case is, and if it could be solved with a better-typed design

IMHO the "plugin/extension" model is the best for the current phase of Dhall's life. This can be done by adding a builtin, but that can often be avoided because functions...

Could you have `Expr` and `NormalizationExpr` or something to model that these functions are only valid when constructing an application to normalize?

>To give another instance of not having octal numerals handled well in Dhall > mode: 0644 > >Converting it to dhall strips the leading zero: If the leading zero is...

@jdoss the linked issue appears to be asking to be allowed to write octal numbers *as though* they were decimal numbers. I'm saying that if the output format supports octal...

Relatedly, it seems that @jdoss has found a bug in yaml-to-dhall: namely, that YAML treats leading zero as octal, but the resulting Dhall ends up containing the octal digits as...

> I’d like to see e.g. user tooling discourage the manual use of indexing nonetheless, encouraging the user to explicitely re-name variables at definition site instead. Why? This is a...

My objection is already noted in #552 since the whole premise of that ticket was that we could stand to do the opposite on some existing built-ins. I, too, am...

‎I think a good first step could be creating a proxy server or similar that converts json/yaml/toml/cbor/xml to Dhall and then you can import from URLs there.

In the same vein as my proxy server idea, we could extend the language to allow     ./path/to/json via json-to-dhall Which would call a locally-installed conversion tool.