Mann mit Hut

@sjakobi Thank you for your investigations on that topic! - IMHO we should move the `FromJSON CharacterSet` instance to the 'dhall-lsp-server' package provided we can get rid of the 'aeson'...

> I'm somewhat skeptical that we can remove Dhall.Optics without increasing our dependence on other heavy-weight packages. https://hackage.haskell.org/package/prolens is lightweight and looks interesting though… I share your concerns but I...

@Gabriel439 I see that solving this by a Cabal Flag is tempting but I see some downsides of this approach as well: - If `no-cli` defaults to `false` it is...

AFAIK there is none at the moment. You might be interested in the discussion of #1092. #1121 is somehow related as well.

@Gabriel439 I think I prefer the first option for the following reason: With the `0x"` prefix it is immediately clear that we deal with a blob whereas in the second...

@Gabriel439 Interestingly when I wrote about extending the blob type I was thinking more about `base32:` or `base64:` encodings rather than binary or octal representations and I have no idea...

I gave it a shot and split the `Dhall.Syntax` module in https://github.com/mmhat/dhall-haskell/tree/2313-split-syntax. The stats are a bit better: > I am however not sure if that is the right way...

Thanks for the feedback! Although I think it would be good to move the builtins to a separate type I share the concerns of @sjakobi. I drafted the solution I...

I'd vote for something like: ```dhall forall (a : Type) -> let EntryType = < Directory : List a | File : Text > let Entry = { name :...

@harris-chris A workaround for that looks like: ```dhall let empty_directory = { empty = None Text } in { this_is_an_empty_directory = empty_directory } ``` Admitted, this is not a nice...