gabby

Yeah, we should probably split it into one module per type at this point since it's getting large

This is why I think there needs to be one module per type (e.g. `Dhall.Syntax.{Expr,Binding,RecordField}`), because that would split up the derived instances

Sorry for the late reply. I'm in favor of any of the proposed fixes, and I very much support factoring out builtins into a separate type (even if that's a...

It's not possible using the currently available built-ins, mainly because we currently don't support builtins that enable `Text` equality comparisons. I think the closest related issue is https://github.com/dhall-lang/dhall-lang/issues/979

I think the first step is deciding what subdomain of `dhall-lang.org` to use (since `docs.dhall-lang.org` is already taken). Then we could start hosting documentation for a few selected packages (e.g....

How did you install `dhall-to-json`?

I tried to reproduce using `dhall-json-1.7.7` inside of a `fish` shell (both obtained from Nixpkgs) but I was unable to reproduce the problem and the auto-completion worked correctly for me

@ocharles: The main issue is that this would lead to ambiguous parses for expressions like this one: ```dhall f λ(x : Natural) → x + 1 ``` … which could...

@ocharles: What I mean is that it's not clear how to encode that extends forever rule in terms of the ABNF or ordinary precedence rules. If I remember correctly, some...

Yeah, I think we should treat each row as a record with fields named `_1`, `_2`, …, but still perform type inference I don't think we need to provide special...