Accessing values of environment variables about dhall-haskell

[Gabriella439]

What is the motivation for providing support for environment variables, though? The reason I ask is that any program that takes environment variables implicitly could be done by reformulating the program as a function. For example, your code could be written as:

    λ(ENV : { FOO : Text, BAR : Text })
→   { foo = ENV.BAR }

... and instead of running:

$ FOO=foo BAR=bar dhall <<< './example'

... you could supply the desired variables as an ordinary function argument when invoking the expression:

$ dhall <<< './example { FOO = "foo", BAR = "bar" }'

... or if you are really constrained to obtain the values from environment variables, you could even do:

$ dhall <<< "./example { FOO = \"${FOO}\", BAR = \"${BAR}\" }"

[Gabriella439]

No. Dhall can only import values via file paths or URLs

[newhoggy]

Do you see handling of environment variables as something that should be external do Dhall?

[Gabriella439]

Actually, I could add support for reading in Dhall expressions via environment variables, using something like this syntax:

{ foo = ${BAR}
}

However, there are two issues with that:

• I might want to reserve the same syntax for interpolating Text into a string literal, like this:

  let txt = "Hello" in "${txt} world!"
  

  ... and it might be confusing to use the same syntax in two different ways

• Imported environment variables would have to be valid Dhall expressions, meaning that if you
  wanted to import Text, then you'd have to define the environment variable like this:

  EXAMPLE='"Test"'
  

[newhoggy]

I can see your point.

What if there was an implicit global let binding that has all the environment variables in them as strings?

For example:

{ foo = ENV.BAR
}

would imply:

let ENV = { BAR = <string-value-of-BAR> } in
{ foo = ENV.BAR
}

[newhoggy]

In the last case, it will mostly work except when the environment variable needs to be escaped, which is the tricky bit.

Perhaps all we need is a env-to-dhall command line tool that does all the necessary escaping?

dhall <<< "λ(ENV : $(env-to-dhall)) → { foo = ENV.BAR }"

Or:

dhall <<< "λ(ENV : $(env-to-dhall)) → ./config"

[Gabriella439]

Hmmm. I would prefer reading environment variables directly within Dhall as a built-in mechanism rather than provide an env-to-dhall executable

The main issue with env-to-dhall or an Env record in general is that dhall does not allow records to hold fields which are types or kinds. So if one of your environment variables is a type or kind you will get a type error when type-checking the Env record

The second issue (when I thought about this more) is that an env-to-dhall mechanism does not support transitively resolving environment variables. In other words, if an environment variable references another environment variable then Dhall should support that (and do basic cycle checking like it does for files/URLs).

So what I'll probably do is add something like env://FOO to reference the environment variable FOO in Dhall. However, FOO will need to be a valid Dhall expression, meaning that if you want to import a Text string then the contents of FOO need to be quoted.

So in other words, you could do:

$ FOO='"foo"' BAR='1' dhall <<< '{ foo = env://FOO , bar = env://BAR }'
{ bar : Integer, foo : Text }

{ bar = 1, foo = "foo" }

How does that sound?

[newhoggy]

That sounds really good.

Although being able embed variables as string is also useful. I don't mind having to type extra to get it. For example, I'd be happy with env+text://FOO. Even file+text://pubrung.gpg would be helpful too.

[Gabriella439]

I just realized that env://FOO is a misleading URI since it implies that FOO is the authority as opposed to the path. It seems like env:FOO is the more appropriate URI

I also like the idea of using +text in the scheme to denote that we expect unquoted Text. I'll implement that, too

[newhoggy]

Good spot. Thanks!

[Gabriella439]

Alright, the first part of this is done in 11ceab1 (supporting env:NAME syntax). The env+text and file+text support will come in a subsequent commit

[newhoggy]

Looking good!

[newhoggy]

I just discovered a case that might need better dhall support:

circle-cli-exe:
↳ ./project.config

Error: Invalid input

project.config:1:17: error: expected: "''",
    "(", "+", "-", "[", "\8704",
    "\955", "\\", "forall", "if",
    "let", "merge", built-in value,
    double, import, integer, label,
    list literal, natural,
    record literal, record type,
    string, union literal,
    union type
{ environment = ~/.circle/project-config/haskell-works.config
                ^

[newhoggy]

At the moment, I'm required to put the absolute path in:

{ environment = /Users/jky/.circle/project-config/haskell-works.config
}

[Gabriella439]

Could I propose an alternative syntax for importing raw Text? I was thinking of adding an as Text suffix to the path in order to import it as a raw Text literal, like this:

{ foo = /foo as Text
, bar = env:HOME as Text
, baz = http://example.com as Text
}

Would that be alright?

[Gabriella439]

I put up a PR for the as Text proposal here: #34

[newhoggy]

👍

[newhoggy]

Thanks so much!

[Gabriella439]

You're welcome! :)

[feliksik]

This is actually a very nice feature to manage global cross cutting concerns nicely. This makes it very powerful, especially since it is also evaluating file imports. Great job!

[Gabriella439]

@feliksik: Thanks 🙂