glen/husht
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Update Block Results

Glen Whitney 2024-08-30 22:32:16 +00:00
parent bb67aec303
commit 9a5dcd3268
1 changed files with 9 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
Block-Results.md

@ -1,5 +1,7 @@
In Rust, a block that ends with a semicolon evaluates to `()`, and a block that doesn't end with a semicolon evaluates to the value of its last expression. In Husht, we want semicolons to be unnecessary, so how do we make this distinction? Here are some ideas. In Rust, a block that ends with a semicolon evaluates to `()`, and a block that doesn't end with a semicolon evaluates to the value of its last expression. In Husht, we want semicolons to be unnecessary, so how do we make this distinction? Here are some ideas.
_Glen added a proposal at the bottom_
### Explicitly mark results ### Explicitly mark results
To indicate that a block evaluates to its last expression, you mark the last expression with a special token. This inverts the Rust convention, in the sense that you indicate a block result by the presence of a token rather than the absence of one. To indicate that a block evaluates to its last expression, you mark the last expression with a special token. This inverts the Rust convention, in the sense that you indicate a block result by the presence of a token rather than the absence of one.
@ -100,3 +102,9 @@ Cons
``` ```
gives the error "`if` and `else` have incompatible types" error. Allowing implicit coercion to `()` might mean we instead get the error "cannot multiply `()` by `()`" in the expression `x*x`, making it harder to figure out what and where the problem is. gives the error "`if` and `else` have incompatible types" error. Allowing implicit coercion to `()` might mean we instead get the error "cannot multiply `()` by `()`" in the expression `x*x`, making it harder to figure out what and where the problem is.
### Glen's proposal
Husht will generally be semicolon free. I feel like most blocks will actually be fine with returning their last expression's value. So could we start with using _exactly_ Rust's convention? In other words, if there is no semicolon on a block's last expression, its value is returned. If there is a semicolon, then its value is dropped/suppressed (whichever it actually is) and the block returns Unit. Since we are not using semicolon for anything else in Husht (except possibly if you for some reason really want two statements on one line), it seems perfectly fine to use it for this. So I propose we start this way -- will clearly be super easy to implement -- and see if there end up being an annoying amount of semicolons that we need to have. My guess is that it will be a reasonably small handful, which will be fine. They do mean something, after all, so they are not WET (write everything twice) -- they carry actual independent information, in that block-final position.
If it turns out that a clear majority of block-final expressions are needing semicolons and we can't come up with a good, typing-free "80% rule" for when Husht should insert them, we could as you suggest flip the scrip and always insert them, adopting one of your proposed notations for explicitly suppressing them.