On "idiomaticness" of dynamic dhall services

#1

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?

2 Likes
#2

@jle: I think it’s perfectly normal and idiomatic to do that. At most, I think there needs to be a better way to selectively freeze imports (perhaps with the support of the language server within an editor)

#3

@Gabriel439 what do you think about a keyword (no-cache?) that signifies an intentional desire to never freeze the import, that would be placed where the frozen hash would otherwise go?

You may not even have to change the language semantics - if I recall correctly, the decision to spell out sha256:... was so that different hash algorithms could be supported. So maybe allow expressions to be “frozen” as none:_, where none is a special “hash” where all expressions evaluate to _.

#4

@ari-becker: I’m a bit reluctant to add things to the language that are only relevant to the tooling. My inclination here is to maybe provide a domain whitelist when freezing imports

#5

Thank you for the insights.

I guess in my mind, I had the impression that a well structured dhall configuration should be ‘pure’: evaluating the same dhall configuration file twice (in the same environment) should always return the same expression. but this might be a limiting view of things.

Still, this view has been helpful to me, and maybe that’s why I feel a little uncomfortable letting go of it in an ‘implicit’ way. Just some thoughts :slight_smile:

1 Like