gabby

@singpolyma makes a good point that a native language binding could support marshaling higher-order functions (i.e. marshaling in a function whose input(s) are functions from the host language). In fact,...

@Profpatsch: So I took a stab at this and it's actually harder than I thought. The issue is that once you add a constructor like this to the `Expr` type:...

@singpolyma: We already do. `NormalizationExpr` is `Dhall.Eval.Val`. The hard part is that we don't expose `NormalizationExpr` in the public API yet, and even if we did we'd have the same...

Personally I'm starting to lean towards towards proposing support for `Text` built-ins that do not permit introspection (See: https://discourse.dhall-lang.org/t/text-manipulation-functions/176/16?u=gabriel439) and `lowercase` is one such function that would be safe according...

@ad-si: What about adding a primitive that could also lowercase Unicode, too? I don't think it would be much more difficult to standardize than the ASCII-only version.

The only reason I haven't standardized a bunch of stuff recently is because I've been slowly mechanizing the standard first, to make it easier for both new and existing implementations...

Oh, I guess it is trickier than I thought. I just did a bit more research and apparently uppercasing and lowercasing a string properly in Unicode is locale-sensitive. The one...

I put up a pull request to implement the ASCII version in the Prelude: https://github.com/dhall-lang/dhall-lang/pull/1164

@vojtechkral: Yes, you can do this using the `json-to-dhall` utility. The utility was written to convert JSON to Dhall given a Dhall schema but can also be used to just...

@vojtechkral: If your application is written in Haskell then you can use the `dhall-json` package which exposes the same functionality as a Haskell API. This is the relevant function: https://hackage.haskell.org/package/dhall-json-1.6.1/docs/Dhall-JSONToDhall.html#v:dhallFromJSON