dhall freeze --inplace creates invalid expression when using headers from file

[timbertson-zd]

I can't make sense of the error but I don't think I'm doing anything wrong, so here's a minimal repro:

(I'm using headers for authenticating to a private repo, but I'm using a public resource here for ease of demonstration)

remote.dhall

https://raw.githubusercontent.com/dhall-lang/dhall-lang/v12.0.0/Prelude/Bool/not using ./Headers.dhall

Headers.dhall

toMap
  { User-Agent = "my-dhall-app"
  , Accept = "application/vnd.github.4.raw"
  }

---

$ dhall --file remote.dhall
λ(b : Bool) → b == False
$ dhall freeze --inplace remote.dhall
$ cat remote.dhall
https://raw.githubusercontent.com/dhall-lang/dhall-lang/v12.0.0/Prelude/Bool/not using ./Headers.dhall sha256:723df402df24377d8a853afed08d9d69a0a6d86e2e5b2bac8960b0d4756c7dc4
$ dhall --file remote.dhall
dhall:


Error: Expression doesn't match annotation

- List …
+ … → …

1│                                                                                        ./Headers.dhall sha256:723df402df24377d8a853afed08d9d69a0a6d86e2e5b2bac8960b0d4756c7dc4 : List { mapKey : Text, mapValue : Text }

Note that if I inline the headers expression, it works. So it's something to do with externalising Headers.dhall.

[timbertson-zd]

(using dhall 1.29.0)

[ari-becker]

Can confirm.

The parser thinks that the supplied hash is for the Headers.dhall, not for the remote import.

If you try to force it by putting parentheses around the remote import and the using ./Headers.dhall then you get

Error: Not a function

3│   723 df402df24377d8a853afed08d9d69a0a6d86e2e5b2bac8960b0d4756c7dc4

Running dhall format on the original expression with the parentheses added results in

  https://raw.githubusercontent.com/dhall-lang/dhall-lang/v12.0.0/Prelude/Bool/not using ./Headers.dhall
    sha256
: 723 df402df24377d8a853afed08d9d69a0a6d86e2e5b2bac8960b0d4756c7dc4

which explains the new error.

Older related bug: #1093

[timbertson-zd]

After more testing, if I change ./Headers.dhall to (./Headers.dhall), it also works. But dhall freeze strips those next time I run it, so it's not a useful workaround.

[Gabriella439]

This is due to two separate issues:

• The standard grammar is ambiguous (which is easy for me to fix)

• The Haskell implementation allows customizing the import parser

  Even if I fix the standard grammar, I can't fix the Haskell implementation to match unless I drop support for parsing customizable imports

I'm actually personally fine dropping support for the customizable parsing (since it makes my life much easier and allows us to make all sorts of other parsing improvements, like performance and better error messages)

However, I wanted to check with people if they're fine losing support for customizable import parsing.

[timbertson-zd]

parsing customizable imports

What's that, exactly? I assume it's only available from the Haskell API, not commandline tools like `dhall` itself?

[Gabriella439]

@timbertson-zd: That's correct. It's a feature of the Haskell API, not the command line interface

[ari-becker]

Documenting my current workaround to split into separate files to force correct parsing:

headers.dhall:

[ { header = "Authorization", value = "token ${env:GITHUB_TOKEN as Text}" } ]

Private.dhall:

https://raw.githubusercontent.com/myorg/myrepo/mytag/Private.dhall using ./headers.dhall

imports.dhall:

{ Private =
    ./Private.dhall sha256:01234567890...abcdef
}