Missing environments variables are reported one by one

[clementd-fretlink]

With the following dhall expression { env1 = env:ENV1 as Text, env2 = env:ENV2 as Text}, and neither of ENV1 nor ENV2 defined,

the reported error is

↳ env:ENV1 as Text

Error: Missing environment variable

↳ ENV1

1:                    env:ENV1 as Text

It'd be better to have all environment variables (that we know of at this point) listed. In this case, we could know about both ENV1 and ENV2 before having to resolve anything.

[clementd-fretlink]

I'd be willing to work on this issue, but I'm not entirely sure what would be the best way to go about it. From what I understand in Import.hs and Import/Types.hs, imports are resolved with a depth-first traversal.

[Gabriella439]

@clementd-fretlink: I believe you could change the import Monad to use Validation or ValidationT, similar to what you've already done in #1011

[divarvel]

From what I understand, the import errors are handled directly by IO as exceptions (throwMissingImport has MonadCatch constraint, and the actual monad in which imports are resolved is StateT (Status IO) IO Resolved).

If I understand correctly, that would require me to change StateT (Status IO) IO Resolved to StateT (Status IO) IO (Validation ImportError Resolved) and stop using MonadCatch for these errors (as monadic behaviour is not what we want here). I'm not 100% sure where is the chained imports behaviour defined (here, we want monadic behaviour), and where the "resolve all imports declared in the current expression" behaviour is set (there, we want applicative behaviour).

In any case, I think it will require some changes, and I don't have a clear enough mental picture of how things work.

[Profpatsch]

and stop using MonadCatch for these errors (as monadic behaviour is not what we want here).

Yes please.

In any case, I think it will require some changes, and I don't have a clear enough mental picture of how things work.

I suggest you change the type and just follow the type errors, there shouldn’t be lots of magic involved.

[clementd-fretlink]

I suggest you change the type and just follow the type errors, there shouldn’t be lots of magic involved.

I'm currently trying that: https://github.com/divarvel/dhall-haskell/commits/accumulate-import-errors

For now, all I do is reproducing monadic behaviour with Validation. I don't see where errors can actually be accumulated.

[flip111]

Does this issue also cover the one-by-one reporting of records missing a required key?

Noticed an issue about this here https://github.com/purescript/spago/issues/604

[sjakobi]

@flip111 The error message reported in https://github.com/purescript/spago/issues/604 doesn't look like it's produced in the dhall library – at least no recent version.

Although if it was, it should probably be a separate issue here: Type-checking records is handled quite differently than resolving imports.