Add prelude.utils.mapBuildInfo.

[quasicomputational]

IMO, this is a function that highlights how dhall-to-cabal is an advance on hpack: the best feature of hpack, setting ghc-options at the top level and then having them apply to all components without any per-component effort, is now really easy to implement. It was writable before the latest Dhall version, but record projection by expression turns it from horrible to just mildly repetetive.

Tests are actually passing but I don't think its ready to merge on two counts:

• Record projection by expression doesn't allow the expression to be a variable dhall-haskell#1009 means that, in mapBuildInfo.dhall, the BuildInfo used as a field selector has to be an import. This hack is localised and could be noted for later removal and then merged, but...

• We'll want to work out what to do about the imports from Dhall's prelude. I don't really like the option of leaving them as HTTP URLs. Including the prelude as a submodule would be a bit awkward, not least because, as the files are extensionless, we can't use Cabal's wildcards to include them in extra-source-files. (Remove the concept of "file extension" from data-files/extra-source-files wildcards haskell/cabal#5883 is the discussion on lifting that requirement.) Also, submodules are terrible and are always breaking in inscrutable ways. I guess that that leaves directly copying the functions that are used?

[ocharles]

#1009 is merged now, but I don't understand the second point. What's wrong with HTTP URLs?

[quasicomputational]

Ah, it's the non-self-containment, and how it'll hit the network at runtime. A secondary problem is that it's mutable, so there's no guarantee that the Dhall being fetched will work with the user's version.

A third option occurs to me: we could run dhall resolve at build time and distribute a 'statically linked' version of dhall/, which has the benefit of clean source but also self-containment for users.

[ocharles]

Ah, it's the non-self-containment, and how it'll hit the network at runtime

Only if it's not in the cache.

A secondary problem is that it's mutable, so there's no guarantee that the Dhall being fetched will work with the user's version.

That's just a case for versioning. We do have Git tag's that we should be using, and we should be using dhall freeze to add hashes for caching compatibility.

Would that be sufficient?

[quasicomputational]

I guess the cache is OK, though making sure it's filled is presently a bit clunky.

OK - let's go with HTTP; if it turns out to be a problem, there are always options.

[quasicomputational]

I've done some further thinking, and I realised that HTTP doesn't necessarily mean hitting the network - it's imaginable that, e.g., Dhall will get clever enough that it'll be able to resolve HTTP imports by using provided signed HTTP exchanges. That it's liable to hit the network today, and preventing that relies on the vagaries of cache invalidation, is unfortunate.

[quasicomputational]

Blocked on dhall-lang/dhall-lang#670, for version-pinned imports of the prelude from dhall-lang.org.

[quasicomputational]

Ah, and also on #179, because of that projection bug that was fixed in 1.25.