gabby

I would prefer to go in the other direction: slowly remove potentially confusing (to humans) parses from the grammar

I might not get to this soon, but I'd accept a pull request to add this

@brendanhay: Probably the most direct route would be to build a custom Dhall interpreter to supply your own built-ins. For more details on how to do that, see: https://docs.dhall-lang.org/howtos/How-to-add-a-new-built-in-function.html You...

@sjakobi: α-normalization can be used on expressions that have not been β-normalized. It's not the case in the typical interpretation path, but it should be allowed This is similar to...

@sjakobi: It's mainly because if there is a sensible way to implement α-normalization it seems odd not to specify how to do it I don't think implementations necessarily need to...

@sjakobi: Sure, I would be fine with that

@brendanhay: Note that #110 just changed the types to more accurately match the OpenAPI spec. For example the `externalDocumentation` field you mentioned is now properly `Optional` in its own right:...

@brendanhay: Yeah, we have to write a Dhall JSONSchema package anyway, since it would be pretty difficult for the `dhall-kubernetes-generator` to automatically infer the correct recursive type anyway. The non-trivial...

Just updating on this: apparently JSON Schema is *waaaaaay* more complicated than I realize, to the point where it's easier to implement `dhall-to-{json,yaml,yaml-ng}` support for recursive types rather than to...

@AdamSaleh: I agree! I've also wanted this feature and it seems like an obvious thing to do to take advantage of the user-supplied schema to suggest completions. I will take...