But this is not unaided Haskell, it's a parser combinator library, isn't it?
Do you see an obvious reason why a similar approach won't work in Rust? E.g. winnow [1] seems to offer declarative enough style, and there are several more parser combinator libraries in Rust.
data Color = Color
{ r :: Word8
, b :: Word8
, c :: Word8
} deriving Show
hex_primary :: Parser Word8
hex_primary = toWord8 <$> sat isHexDigit <*> sat isHexDigit
where toWord8 a b = read ['0', 'x', a, b]
hex_color :: Parser Color
hex_color = do
_ <- char '#'
Color <$> hex_primary <*> hex_primary <*> hex_primary
Sure, it works in Rust, but it's a pretty far cry from being as simple or legible - there's a lot of extra boilerplate in the Rust.
I think it's a stretch to call parser combinator code in Haskell simple or legible. Most Haskell code is simple and legible if you know enough Haskell to read it, but Haskell isn't exactly a simple or legible language.
Haskell demonstrates the use of parser combinators very well, but I'd still use parser combinators in another language. Parser combinators are implemented in plenty of languages, including Rust, and actually doing anything with the parsed output becomes a lot easier once you leave the Haskell domain.
> it's a stretch to call parser combinator code in Haskell simple or legible
Parser combinators in Haskell are exactly simple and legible.
When you think of them as an embedded DSL, Haskell is just a well-suited medium because it allows for very clean syntax: Function application is whitespace, and currying and partial application allows for a high degree of composability simply with parentheses and value bindings.
They're simple and legible, if you just want to know what a combinator does, and you don't need to understand how they work underneath. And you could argue that you don't need to to make practical use of them, just like you don't need to understand how LINQ works in C# to use and value them.
The catch comes with the incomprehensible error messages that are a consequence of the DSL being embedded: Once you forget a partial application, or you put a parenthesis the wrong way, you'll not understand why or where it goes wrong. So no, they're not as easy to work with as they are simple and legible.
I'd say Haskell is even simpler than Rust: the syntactic sugar of monads/do-notation makes writing parsers easy. The same sugar transfers to most other problem domains.
Yeah, that one appeals to me more than the morrow example. The difference between that and the Haskell, other than any particular choices I made about use of operators instead of more explicit bindings, is really just syntactic decoration around functions and such.
But it doesn't take much to go from 0 to a parser combinator library. I roll my own each year for advent of code. It starts at like 100 lines of code (which practically writes itself - very hard to stray outside of what the types enforce) and I grow it a bit over the month when I find missing niceties.
Do you see an obvious reason why a similar approach won't work in Rust? E.g. winnow [1] seems to offer declarative enough style, and there are several more parser combinator libraries in Rust.
[1]: https://docs.rs/winnow/latest/winnow/