-
Notifications
You must be signed in to change notification settings - Fork 262
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
Do-notation desugaring to monadic Bind #455
Conversation
…refix in next pass
…ll test, then resolve
…it makes sense to switch to a do-notation flag for expression instead
…on, but resolver throw error if they are find outside of do-notation. Still need to fill in the resolving of MonadicBindExpr
…n calc statement (otherwise BinaryExpr may captures the op
…xpr, will do more testing
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
… ResolvedExpression is set.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Some of the test cases are failing at the moment due to "do" being used as a function/method name (some of these fails at the use of the function rather than at declaration). I could try to make it always fail at declaration, or try to fix the parser so that it doesn't get tripped by non-blocks' "do" |
Thanks for the initiative to add monadic binds to Dafny. I would like to see these, but think they should be more analogous to the
So, an expression (which can occur anywhere an expression can occur, not just inside some
where
To distinguish this construct from the similar
If neither or both applies, some error should be generated. If it cannot be determined from what's currently known about the type of The resolution of the types for the parameters passed to I'm suggesting the monadic-bind rewrite use just |
…ng let-binding depending of the context, as discussed in PR 455
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Some thoughts on @RustanLeino's comments. Rather than introduce another
This would reduce the power of Monads quite a lot so I don't think it would be a great solution. I can't think of the right set of functions to support classic
This strikes me as fragile, since refactoring in what should be a semantically-equivalent way would break verification very easily. I'm also starting to think that we shouldn't try to retcon the existing On a similar subject, will we end up missing a lot of the appeal of monads if we can't express the monad concept as a |
There are many good comments above and in the discussions linked from the above. Syntactic issues aside, I think we first need to find a good way to deal with the partial expressions that require preconditions above. Should we:
I think we need to resolve this question to go on. Overall, the inclusion of these monadic constructs seems a bit premature at this time. Do we have any interesting use cases that someone would actually like to write? Then, we could let those inform the design. Alternatively, we could go for a restrictive design (I suggest the one in my first comment in the discussion above), so that we can play with it, and then hope to figure out where to go from there? Opinions? |
…n (which get forwarded to the desugared lambda-expression). Rerun coco, add a test case (from Rustan) in MonadicBind
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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 mention my hesitation about the no-LHS version of :-
, but maybe that can be resolved later.
All other comments pertain to code style. Please update the settings in your IDE accordingly.
Test/monadic/MonadicBind.dfy
Outdated
@@ -0,0 +1,77 @@ | |||
// RUN: %dafny /compile:0 "%s" > "%t" |
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 would like to see more tests: some that don't use specifications, some that use reads
.
Also, since these are expected to verify, there might as well be some compiling tests (so change to /compile:3
and add a Main
).
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
I still have reservations about edge cases in ambiguity between LetOrFail |
|
||
class Cell { | ||
var data: int | ||
} |
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.
What is class Cell
used for?
case Cons(x, _) => Some(x) | ||
} | ||
|
||
function method G(list: List): Option { |
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.
You're using List
and Option
without giving a type argument. I'd also test it with List<A>
and Option<A>
.
var cdr :- Tail(list); | ||
var cddr :- Tail(cdr); | ||
Head(cddr) | ||
} |
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.
All the examples involving generics go from a List<T>
to List<T>
, where T
remains the same. I'd also test an example where the function you pass to Bind
goes from List<T>
to List<U>
, where T
and U
are different, and also one where it goes from Foo<T>
to Bar<U>
, just to see how this interacts with type inference.
{ | ||
if this == None then None else f(get) | ||
} | ||
} |
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.
You're intending to implement quite a generic feature, so it would be nice to not only test it for the Option
monad, but also for some other monad, maybe for the State
monad? Or what other monads are people intending to use in Dafny?
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.
+1 - this also needs to test the case where a type defines both Bind and IsFailure/PropagateFailure/Extract, since the syntax is ambiguous there
Upon further consideration, we will not include this feature in the language at this time. There are some issues to be resolved around how to write verifying code with the functions that are being generated. |
Feature review.
"do { Expression}" allows for monadic bind "<-" to appear.
"x <- e1; e2" desugars to "Bind(e1, x => e2)"
"P x <- e1; e2" desugars to "match e1
P x => e2"
Both MonadicBindExpr and DoNotationExpr are ConcreteSyntaxExpression (i.e. they disappear after the resolving phase)