this post was submitted on 14 Aug 2023
1414 points (98.0% liked)
Programmer Humor
19623 readers
96 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Note: Lemmy code blocks don't play nice with some symbols, specifically < and & in the following code examples
This isn't a language level issue really though, Haskell can be equally ergonomic.
The weird thing about
?.
is that it's actually overloaded, it can mean:A?
that returnsB?
A?
that returnsB
you'd end up with
B?
in either caseSay you have these functions
and you want to construct the following using these 3 functions
in a Rust-type syntax, you'd call
in Haskell you'd have two different operators here
however you can define this type class
and then get roughly the same syntax as rust without introducing a new language feature
though this is more general than just
Maybe
s (it works with any functor/monad), and maybe you wouldn't want it to be. In that case you'd do thisrestricting it to only maybes could also theoretically help type inference.
I was thinking along the lines of "you can't easily get at the wrapped type". To get at
b
instead ofMaybe b
you need to either use do-notation or lambdas (which do-notation is supposed to eliminate because they're awkward in a monadic context) whereas Rust will gladly hand you thatb
in the middle of an expression, and doesn't force you to name the point.Or to give a concrete example,
if foo()? {...}
is rather awkward in Haskell, you end up writing things like, though of course baz is completely generic and can be factored out. I think I called it "cap" in my Haskell days, for "consequent-alternative-predicate".
Flattening Functors and Monads syntax-wise is neat but it's not getting you all the way. But it's the Haskell way: Instead of macros, use tons upon tons of trivial functions :)