In that case, while you can always try to discuss it on IRLO, realistically speaking the probability of that being implemented is pretty small I'm afraid.
I knew the chance was pretty small, so it’s just a wish. And/or/not would’ve been added a long time ago if it was gonna happen.
Even though I prefer textual and/or/not over symbolic &&/||/!, mixing them is worse. If both of them exist, then everyone has to learn to read both of them. And anyone who contributes to more than one project has to memorize the idiosyncratic preferences of the maintainer.
Rust should not add and/or/not aliases. It has made its choice and should stick with it.
While they’re at it, Rust should get rid of one of the module directory structures, going with either mymod/mod.rs or mymod.rs. I don’t care which choice Rust makes. Just pick one.
5 Likes
It's a pity that I can't have them, but I think you're right. Thank you for helping me figure this out.
This reminds me: if we're breaking backwards compatibility, please go with foo/foo.rs. To me, it's objectively better than mod.rs.
Realistically, I actually think the dual module styles can be helpful. Having an entire folder per module can get ugly fast; and contrariwise, when you have multiple large submodules, it can be extremely nice to have each module self contained in a folder, instead of spilling out into the parent folder. IOW, I don't think either style can be removed without severe damage to old and new projects alike.
6 Likes
How would you handle wanting to have the equivalent of
mod foo {
mod foo { /* … */ }
}
with that file structure? mod is a keyword, so it doesn't apply to foo/mod.rs.
2 Likes
That is the only downside, but I think I'm personally okay with that. I've never seen that module structure before. I can understand people not liking it.
Complete Transformer from scratch using Rust.
Halfway there with a functional Neural Network till now.
Just a matter of understanding the inner workings and math of transformer to implement that too.
Functors! Real functors are a really cool concept, and Rust would benefit from them. Basic mathematical formulas, such as the Fourier transformation, are based on functors. Furthermore, without functors, real monads cannot be implemented in Rust. Monads are one of the coolest features of Haskell.
The Typesignature of a functor is (a -> b) -> f(a) -> f(y)
1 Like
I prefer if Rust considers the Kotlin creator way, when you do programming in Rust less formal. Rust provides a good diagnostic and ways to fix compilation error, but why instead you can just tell less formal what you need and then Rust compiler can produce a right code?
Having studied Fourier Analysis in Uni and having implemented my own Fast Fourier Transform I have never heard the word "functor" associated with them. So I'm curious, how does an FFT look in Haskell?
1 Like