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

Update Other

Glen Whitney 2024-08-27 18:36:37 +00:00
parent 6ec3812148
commit 1c2af0bbe4
1 changed files with 6 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
Other.md

@ -1,7 +1,12 @@
### In-line conditionals ### In-line conditionals
Let's suppose you want to increment `x` if `right` is true and decrement it otherwise. In C you might write `x += right ? 1 : -1;`. Let's suppose you want to increment `x` if `right` is true and decrement it otherwise. In C you might write `x += right ? 1 : -1;`.
In the Husht examples, the only in-line two-way conditionals that come up would render this as `x += if right then 1 else -1` or (inherited from Rust) `x += if right {1} else {-1}`. Both of these have a lot of syntax for the semantic payoff. Is there a need for a more compact inline choice for a binary? There a [stackOverflow answer](https://stackoverflow.com/a/73965190) on this topic that suggests adding an `IfElse` trait to the boolean type so that you can write `(a < b).ifelse(1, -1)`. So in Husht we could take this just a step further (and in a nod to C) allow `x += right.? 1, -1` and `a < b .? 1, -1`. In the Husht examples, the only in-line two-way conditionals that come up would render this as `x += if right then 1 else -1` or (inherited from Rust) `x += if right {1} else {-1}`. Both of these have a lot of syntax for the semantic payoff. Is there a need for a more compact inline choice for a binary? There is a [stackOverflow answer](https://stackoverflow.com/a/73965190) on this topic that suggests adding an `IfElse` trait to the boolean type so that you can write `(a < b).ifelse(1, -1)`. So in Husht we could take this just a step further (and in a nod to C) allow `x += right.? 1, -1` and `a < b .? 1, -1`.
### Mandatory return types ### Mandatory return types
A function `fn myconst() -> u32 { 12u32 }` must declare its return type even though it's crushingly obvious from the return value. This is actually not DRY. Should we work to remove this requirement and allow return types to be elided when they can be deduced from the function definition? A function `fn myconst() -> u32 { 12u32 }` must declare its return type even though it's crushingly obvious from the return value. This is actually not DRY. Should we work to remove this requirement and allow return types to be elided when they can be deduced from the function definition?
### Building a Husht project
I think the simplest approach would be to use a simple makefile to transform all of the .hsh files to corresponding .rs files in a build directory (and of course, when some .hsh file is newer, it re-does the transform for the files associated with that, leaving unrelated .rs files alone). Then it calls the rust build system, trunk or whatever we are using, capturing any error output and translating the file and line numbers so that they are understandable to the coder. I think that should be it.
In fact, I think I will mock this system up with a bootstrapping version of husht that just inserts braces at indents and outdents, even though that is definitely not a start on a reasonable implementation, just to get the environment set up and establish that our source code has checked-in .hsh source files and the corresponding .rs transformed files.