5 ms·

I don't know. Having written a small parser [0] for Forsyth-Edwards chess notation [1] Haskell takes the cake here in terms of simplicity and legibility; it rea

• nine_k 2y ago
  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. [1]: https://docs.rs/winnow/latest/winnow/ https://docs.rs/winnow/latest/winnow/
  • codebje 2y ago
    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.
    • jeroenhd 2y ago
      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.
      • kreetx 2y ago
        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.
      • sshine 2y ago
        > 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.
    • orf 2y ago
      The nom crate has an RGB parser example: https://docs.rs/nom/latest/nom/#example https://docs.rs/nom/latest/nom/#example It’s slightly longer, but more legible.
      • codebje 2y ago
        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.
  • mrkeen 2y ago
    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.
• PittleyDunkin 2y ago
  Haskell definitely takes the cake in terms of leveraging parser combinators, but you’re still stuck with Haskell to deal with the result.
  • instig007 2y ago
    don't make it sound as if it's bad, it's actually superb on all these levels: the typelevel, the SMP runtime, and throughput.
  • pjmlp 2y ago
    For some of us, "being stuck with Haskell" isn't a problem.
    • anilakar 2y ago
      For the rest, being stuck with real-world problems instead of self-inflicted ones is preferable :-)
      • instig007 2y ago
        re-inventing known language features in inferior languages isn't more real-world, it's a self-inflicting kool-aid thirst ^_^
        • HKH2 2y ago
          Has Cabal been fixed yet?
          • ryandv 2y ago
            Yes. Use stack [0]. [0] https://docs.haskellstack.org/en/stable/ https://docs.haskellstack.org/en/stable/
          • kreetx 2y ago
            Yes, a long time ago [0]. Depending on your needs, stack might still have advantages as the direct tool used by the developer (as it uses cabal underneath anyway). [0] https://stackoverflow.com/a/51016806/4126514 https://stackoverflow.com/a/51016806/4126514
• lynx23 2y ago
  I wouldn't consider FEN a great parsing example, simply because it can be implement in a simple function with a single loop. Just a few days ago, I wrote a FEN "parser" for an experimental quad-bitboard impelementation. It almost wrote itself. P.S.: I am the author of chessIO on Hackage