-
Notifications
You must be signed in to change notification settings - Fork 214
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
Add several new entrypoints to Dhall
module
#2534
Conversation
This adds the following four new high-level entrypoints: - `interpretExpr` - `interpretExprWithSettings` - `fromExpr` - `fromExprWithSettings` … as well as several new utilities for running each phase one at a time, respecting `InputSettings`: - `parseWithSettings` - `resolveWithSettings` - `typecheckWithSettings` - `expectWithSettings` - `normalizeWithSettings` This also refactors the other utilities to use those new phase-based settings. The motivation behind this change is to make it easier for people to work with raw `Expr`s, so that people don't need to craft strings when trying to assemble ASTs to interpret like in this issue: https://stackoverflow.com/questions/77037023/is-there-an-elegant-way-to-override-dhall-records-in-haskell
@Gabriella439 I think it was nice if there was also a function |
Core.throws (Dhall.Parser.exprFromText (view sourceName settings) text) | ||
|
||
-- | Type-check an expression, using the supplied `InputSettings` | ||
typecheckWithSettings :: InputSettings -> Expr Src Void -> IO () |
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.
typecheckWithSettings :: InputSettings -> Expr Src Void -> IO () | |
typecheckWithSettings :: MonadThrow m => InputSettings -> Expr Src Void -> m () |
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'm going to leave this as is for right now (as I'm trying to cut a release soon), and also because a MonadThrow
constraint alone is not enough. It would need to also have MonadIO
, but then you could subsume the MonadThrow
constraint into the MonadIO
constraint (by using liftIO . throwIO
), and then I feel like leaving it as IO
instead of MonadIO
is preferable.
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.
@Gabriella439 I think Dhall.Core.throws
adds the necessity for IO
, not Dhall.TypeChech.typeWith
or Dhall.Parser.exprFromText
. While I am really looking forward to a new release, I thought it might be best to change the API before that and not when it is already published and part of the user interface.
@@ -195,6 +206,68 @@ instance HasEvaluateSettings InputSettings where | |||
instance HasEvaluateSettings EvaluateSettings where | |||
evaluateSettings = id | |||
|
|||
-- | Parse an expression, using the supplied `InputSettings` | |||
parseWithSettings :: InputSettings -> Text -> IO (Expr Src Import) |
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.
parseWithSettings :: InputSettings -> Text -> IO (Expr Src Import) | |
parseWithSettings :: MonadThrow m => InputSettings -> Text -> m (Expr Src Import) |
{-| Type-check an expression against a `Decoder`'s expected type, using the | ||
supplied `InputSettings` | ||
-} | ||
expectWithSettings :: InputSettings -> Decoder a -> Expr Src Void -> IO () |
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.
expectWithSettings :: InputSettings -> Decoder a -> Expr Src Void -> IO () | |
expectWithSettings :: MonadThrow m => InputSettings -> Decoder a -> Expr Src Void -> m () |
This adds the following four new high-level entrypoints:
interpretExpr
interpretExprWithSettings
fromExpr
fromExprWithSettings
… as well as several new utilities for running each phase one at a time, respecting
InputSettings
:parseWithSettings
resolveWithSettings
typecheckWithSettings
expectWithSettings
normalizeWithSettings
This also refactors the other utilities to use those new phase-based settings.
The motivation behind this change is to make it easier for people to work with raw
Expr
s, so that people don't need to craft strings when trying to assemble ASTs to interpret like in this issue:https://stackoverflow.com/questions/77037023/is-there-an-elegant-way-to-override-dhall-records-in-haskell