Just a thought – what would be issues of idiomaticness/conflicts of usage cases with something like a “dynamic” dhall service – an HTTP-facing server that returned dynamically generated dhall files that are meant to be imported into other dhall files?
For an example, there are services like shields.io that dynamically generate an image upon request. For example, a HTTP request to the https://shields.io
at path /github/commit-activity/m/dhall-lang/dhall-haskell.png
returns this dynamically generated this image:
One could imagine imagine a similar HTTP service that generates similar things, like a request to a similar path returning the dhall file { commit_activity = 21 }
, or some different number on every request.
This would make sense if used as an endpoint for an application, like how json works, where you would directly load the dhall file’s information into your application, extract the Natural
, and move on from there.
However…it feels a bit weird if I included this as an import in a dhall file. Mainly, this makes dhall freeze
useless/meaningless … if my dhall file had { the_thing = https://mydhallservice.com/commit_activity }
, this can’t be frozen, because that import would return something different every time…tomorrow it might be 22, or 23.
But it wouldn’t be enough to just say “don’t freeze at the point where you import”, you also have to say “don’t freeze any imports that import that point where you import”, right?
All of the parts fit together mechanically, but I’m not sure if the implications of it make the resulting files unusable. Is there a best practice guide that addresses this sort of thing?