-
Notifications
You must be signed in to change notification settings - Fork 211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Substitutions #1650
Substitutions #1650
Conversation
Substitutions are another way of extending the language: The idea is to to substitute certain variables with expressions defined in the interpreter before type checking. This commit resolves dhall-lang#794. This commit resolves dhall-lang#879.
Interesting! :) Could you give an example of how to use this? |
Aside from a slightly different handling of variables, what advantage does this offer compared to just wrapping the expression with certain |
@sjakobi Have a look at my last commits. I added a section about substitutions to the tutorial. A full working example is included in the test suite. |
@MonoidMusician Although let-wrapping works I always found it rather 'hacky'. I'd argue that the approach in this pull request is cleaner. Besides, it works with |
Hm, it is a bit unclear to me why the Hydra CI is failing. Can anybody help? |
@mmhat: CI requires everything that is exported to be documented |
@MonoidMusician: Another thing this can do that a |
@mmhat: The new |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few random comments. I really this in any case! 👍
dhall/src/Dhall/Tutorial.hs
Outdated
-- > | ||
-- > myexample :: IO Result | ||
-- > myexample = let | ||
-- > evaluateSettings = Lens.over Dhall.substitutions (Data.Map.insert "Result" resultType) Dhall.defaultEvaluateSettings |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder whether it would be better if the collection of substitutions were opaque instead of a plain Map
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since substitutions are a simple mapping and the Map datatype is a common one the user will get an immediate intuition how to construct/update/... the data structure.
I think this contributes more to the usability than an opaque type. Of course it makes it more difficult to change this feature in the future because it might break other peoples code.
I'm not sure about this trade off myself...
@mmhat: I added you as a collaborator, so you can merge whenever you are ready, either by clicking "Squash and merge" when CI is green or by adding the "merge me" label to your pull request (which will take care of auto-merging for you once CI is green) |
Substitutions are another way of extending the language:
The idea is to to substitute certain variables with expressions defined
in the interpreter before type checking.
This commit resolves #794 .
This commit resolves #879 .
This commit resolves #1502 .