Skip to content
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

Use where instead of var for expressions #5914

Open
keyboardDrummer opened this issue Nov 13, 2024 · 2 comments
Open

Use where instead of var for expressions #5914

keyboardDrummer opened this issue Nov 13, 2024 · 2 comments
Labels
kind: enhancement Enhancements, feature requests, etc. These are NOT bugs, but ways we can improve Dafny part: language definition Relating to the Dafny language definition itself

Comments

@keyboardDrummer
Copy link
Member

keyboardDrummer commented Nov 13, 2024

I don't like var expressions, because var is already used in statements so it can make code that is an expression look like a statement:

var x := ..
var y := ..
// are we inside an expression or a statement? it's impossible to tell from there
x := 3 // error: a let-bound variable can not be re-assigned. Aha, we were in an expression!

Also, while for statements the order of code affects the semantics, for expressions it does not, so it is no longer necessary for the definition of variables to come before their usage. I think it is more readable for the definition to come after the usage, since the name is used as a summary of the body, allowing one to read the code top-down.

I propose the following syntax:

function Foo(x: int): int =>
  x + y 
where 
  x := y + z;
  y := 2;
  z := 3;

Where bindings are checked for cyclic dependencies.

Note that I've also replaced the curly braces around the function body with a =>, which Dafny also uses as part of defining lambda expressions. I think this change makes it extra clear that the body of a function is not a statement. I think beginning Dafny users are often confused because they can not use statements inside function bodies, since the curly braces imply that they can.

@keyboardDrummer keyboardDrummer added kind: enhancement Enhancements, feature requests, etc. These are NOT bugs, but ways we can improve Dafny part: language definition Relating to the Dafny language definition itself labels Nov 13, 2024
@robin-aws
Copy link
Member

I love the motivation here at least. Avoiding braces in expressions would also help avoid the ambiguity of {...} between blocks and set displays.

The main thing I don't love in the proposed syntax is the fact that the where "statements" (and we'd have to still allow lemma calls etc) are evaluated top-down, but then the final expressions is up top before all of them. I might prefer something like:

function Foo(x: int): int =>
  let 
    x := y + z;
    y := 2;
    z := 3;
  in
    x + y

That style is super common in functional languages, and it's a smaller syntactic change just localized to mostly StmtExprs, which also improves readability and compactness in compound expressions in statement contexts, like (let x := x := y + z; y := 2; z := 3; in x + y)

@keyboardDrummer
Copy link
Member Author

The main thing I don't love in the proposed syntax is the fact that the where "statements" (and we'd have to still allow lemma calls etc) are evaluated top-down, but then the final expressions is up top before all of them.

Good point, I think this only makes sense if you don't need expression statements at all. Suppose you wouldn't need them, would the top-down order then make sense to you?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: enhancement Enhancements, feature requests, etc. These are NOT bugs, but ways we can improve Dafny part: language definition Relating to the Dafny language definition itself
Projects
None yet
Development

No branches or pull requests

2 participants