gabby

@blamario: There are still issues with adding uninterpreted built-ins to the default scope. Currently, a language binding can rely on the property that if a configuration file has type `Bool`...

@blamario: Never mind. I misunderstood what you are proposing. Now I see that you are proposing that parsing-related built-ins produce results in some sort of `Grammar` `Applicative`/`Monad`. So the type...

@blamario: There is still the issue of how one would specify mutually recursive grammar rules (such as the JSON grammar)

@blamario: Yeah, I understand that this would probably increase the specification complexity. Right now I'm just trying to collect ideas; I'm not in a hurry to make a decision

@Nadrieril: The motivation behind restricting the language is not to protect people from errors in their own code, but rather to protect people from errors in their dependencies. Asking people...

I opened up a related issue for another idea for how to solve the original problem: https://github.com/dhall-lang/dhall-lang/issues/994

@NMerkley: I like the idea of having a separate `Text` type (maybe `String` or `Characters`, to suggest that the value can be decomposed into characters) that permits introspection which can...

@hyperfekt: Yeah, I'm warming up to the idea of generalizing the "import resolution" phase to become an "unsafe stuff" phase, which would include both resolving imports and `Text` manipulation. Then...

@travisbrown: The Haskell implementation had the exact same issue. See this thread starting here: https://github.com/dhall-lang/dhall-haskell/issues/108#issuecomment-425146712. That issue has an even smaller reproduction which is just `((((((((Bool))))))))` Basically, your intuition is...

Alright, so I took an initial stab at creating an RPM for `dhall-haskell` using Nix. Apparently Nixpkgs has infrastructure for doing this correctly and the only issue I ran into...