env:VAR and Unions

toastal · August 14, 2020, 5:00pm

This is what I want to do:

export QUX=foo

let FooBarBaz : Type = < foo | bar | baz >
in env:QUX as FooBarBaz : Type

Currently I’m doing like:

export QUX="($(find-this-files-absolute-path-in-bash)/FooBarBaz.dhall).Type.foo"

This is fine, but people agree that it’s kind of ugly and really ties that env var to Dhall rather than looking rather agnostic.

Is there way to do this as what I wanted? Perhaps it could be done with merge but a) it’s midnight and b) it seems really ugly and not dry merge { foo = FooBar.Baz.Type.foo, ... }. When I see json-to-dhall being able to figure out this string-to-union situation, surely there’s solution.

Goodnight and thanks

jle · August 14, 2020, 5:22pm

Is

export QUX=<foo|bar|baz>.foo

something that is suitable for your case?

toastal · August 14, 2020, 5:28pm

No, because that union could easily change to add new values.

Gabriel439 · August 15, 2020, 3:52am

@toastal: Yeah, we got a similar request on the Functional Programming Slack and created two separate issues to collect ideas for how to address this.

The first issue discusses more general solutions to the problem:

github.com/dhall-lang/dhall-lang

Permit text parsing at import resolution time?

opened 09:51PM - 01 May 20 UTC

Gabriel439

I'm creating an issue to consolidate an idea that has come up in three separate …contexts. The basic idea is to add the ability to import from an arbitrary `Text` source by specifying a custom Dhall parser. Specifically, we would allow `Text` introspection built-ins only within these custom parsers, but not elsewhere within a Dhall program. Here is a concrete example from a recent Discussion on Slack: ```dhall env:ENV as ./parseEnvironment.dhall ``` ... where `./parseEnvironment.dhall` contains: ```dhall let Environment = < Development | Staging | Production > in \(text : Text) -> if Text/equal "prod" text then Some Environment.Production else if Text/equal "staging" text then Some Environment.Staging else if Text/equal "development" text then Some Environment.Development else None Environment ``` ... so that a program can accept an environment variable of the form `ENV=prod` and that gets parsed at import resolution time into a more structured `Environment` union type. The reason I use the `as` keyword here, is because then the current `as Text` functionality just becomes a special case where the parser is the identity function: ```dhall import as Text = import as (\(text : Text) → Some text) ``` ... although if we really want to avoid special-casing `as Text` we could use a separate keyword for this new functionality. The `Text` introspection built-ins would only be in scope for the import-related parsers and would still not be available elsewhere within the program. This would ensure that any weakly-typed logic is pushed to the edge of the system. Two other contexts where this has come up are: * https://github.com/dhall-lang/dhall-lang/issues/121 (Importing from JSON files) If we had customizable parsers we could implement support for parsing JSON expressions in Dhall instead of having to bake JSON support into the language. * https://discourse.dhall-lang.org/t/text-manipulation-functions/176/39 A discourse thread about `Text` manipulation where this idea also came up If people support this idea, the main design decisions that would need to be fleshed out are: * What are the minimal set of new built-ins necessary so that we can ergonomically author these types of parsers People interested in this should check out the Discourse thread which already touched on this subject a bit * What type should the parsing function be? In particular, how should we represent error handling? Return an `Optional` or `< Failure : Text | Result : a >` or something else entirely? The goal is that we want to fail fast and reject a malformed import at import resolution time rather than silently failing with an unexpected value at normalization time. If we can decide on those two things I can do the standardization work

… and the second issue discusses simpler special-purpose solutions:

github.com/dhall-lang/dhall-lang

Importing with union constructors in scope

opened 04:22PM - 04 May 20 UTC

Gabriel439

This is based on a discussion with @drewolson in Slack on alternative ways to so…lve the problem mentioned in https://github.com/dhall-lang/dhall-lang/issues/989 of ergonomically importing a union type. I chose to create a new issue because I didn't want to derail the existing discussion on #989. One idea @drewolson suggested is to add support for an `as UnionType` feature, like this: ```dhall let Example = < prod | staging | development > in env:ENV as Example ``` ... then the Dhall expression imported from the `ENV` environment variable would have the union constructors in scope. So the environment variable would only need to be `ENV=prod`, for example. A related idea, similar to one proposed by @Reisen a while back in https://github.com/dhall-lang/dhall-haskell/issues/676 is to bring local variables into scope (either wholesale or selectively) for the imported expression, like this: ```dhall let prod = Example.prod let staging = Example.staging let development = Example.development in env:ENV context { prod, staging, development } -- This would be the selective approach ``` The main issue I can foresee with both approaches is that the contents of the import would no longer type-check in isolation. One possible variation on the above ideas is to only permit this feature for environment variables (which are more ergonomically constrained and less likely to be interpreted in isolation).

toastal · August 15, 2020, 6:18am

I’ll follow the issues. I could just swear that there was a way around this since json-to-dhall can go from text to Dhall just fine.