Review wanted: dhall-webmanifest

I published my first Dhall package, dhall-webmanifest, for the W3 Web App Manifest file. I’d love to get some sort of feedback since I’m quite green here.

I think I did the { Type, default } thing for fallbacks correctly, but I wasn’t quite sure if I could remove all the Somes (or if I even should bother). There could be some more safety, but I don’t know that I would things to be complicated to do the to Text part. The part where this would help the most is in ExternalApplicationResource the spec says

A valid ExternalApplicationResource dictionary MUST have platform and either an url or an id (or both).

which would lead me to believe there’s a These-like structure, but it’s probably more trouble to use/consume than it’s worth for that safety.

3 Likes

@toastal: The README example could be simplified a little bit using the record completion operator. Specifically, WebAppManifest.ImageResource.default ⫽ { src = "icon.svg" } can be simplified to WebAppManifest.ImageResource::{ src = "icon.svg" } and WebAppManifest.default ⫽ webmanifest : WebAppManifest.Type can be simplified to WebAppManifest::webmanifest

Also, you probably don’t need to provide versions of the files without the .dhall suffix. The Prelude only does so for historical reasons and the new convention is to include the .dhall suffix for better IDE support and syntax highlighting.

1 Like

I just released version 4.0.0. I think I have the entire spec + the candidate ShareTarget added at this point now that I run a test to verify a couple real-world manifests.

You can use it to verify this Discourse’s Web App Manifest file.

curl --http2 --compressed "https://discourse.dhall-lang.org/manifest.json" \
  | json-to-dhall "(https://gitlab.com/toastal/dhall-webmanifest/raw/v4.0.0/Webmanifest/WebAppManifest.dhall sha256:2fda78787b45f8486c90dba86b05d28635b3bae287241245d9a857a08987f5ec).Type"

1 Like