Hacker News Reader

Comment by ryandv | Hacker News Reader

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 reads almost as clearly as BNF, and there is very little technical ceremony involved, letting you focus on the actual grammar of whatever it is you are trying to parse.

[0] https://github.com/ryandv/chesskell/blob/master/src/Chess/Fa...

[1] https://en.wikipedia.org/wiki/Forsyth%E2%80%93Edwards_Notati...

View on HN

Haskell definitely takes the cake in terms of leveraging parser combinators, but you’re still stuck with Haskell to deal with the result.

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.

For some of us, "being stuck with Haskell" isn't a problem.

For the rest, being stuck with real-world problems instead of self-inflicted ones is preferable :-)

re-inventing known language features in inferior languages isn't more real-world, it's a self-inflicting kool-aid thirst ^_^

Has Cabal been fixed yet?

Yes. Use stack [0].

[0] https://docs.haskellstack.org/en/stable/

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

At least since August 2017: https://downloads.haskell.org/~cabal/Cabal-3.0.0.0/doc/users...

You don't need switching to Stack (as other commenters suggest) to have isolated builds and project sandboxes etc. If you want to bootstrap a specific compiler version, a-la nvm/pyenv/opam, use GHCup with Cabal project setup: https://www.haskell.org/ghcup/

Doesn't seems so, otherwise the computing world wouldn't be so full of NIH syndrome. :)

I like haskell a lot, but it's not like there's any shortage of reasons why people don't use it. Replicating parser-combinators in other languages is a huge win.

That's what they call a "win-win".

$ echo "Haskell" | sed 's/ke/-ki'

Has-kill

| sed '/k/sk'

Has-skill

Write the full transform in Haskell?

    {-# LANGUAGE OverloadedStrings #-}

    import Prelude hiding (putStrLn)
    import Data.Text (Text, replace)
    import Data.Text.IO (putStrLn)

    transform :: Text -> Text
    transform = replace "k" "sk" . replace "ke" "-ki" 

    main :: IO ()
    main = putStrLn $ transform "Haskell"

Looks good to me, even as a Haskell ignoramus. I had tried it long back, but found it tough at the time.

What is the reason for hiding the putStrLn of Prelude and importing that of Data.Text.IO?

Prelude takes a `String`, Data.Text.IO works with `Text`. Strings are linked lists of of chars, Text is a more traditional data structure. I tend to write small scripts and use Strings more, but Text is much more efficient for big blocks of text (unsurprisingly). The main reason I used it here was because I couldn't find a `replace` function for `String`, lol.

Thanks.

Since the original sed command took "Haskell" as standard input, why not:

  {-# LANGUAGE OverloadedStrings #-}

  import qualified Data.Text as T
  import qualified Data.Text.IO as T

  main :: IO ()
  main = T.interact (T.replace "k" "sk" . T.replace "ke" "-ki")

Didn't think to, but that looks very slick!

  sed: -e expression #1, char 5: unterminated `s' command

It's like this:

  sed 's/find/replace/'

Whoops, it was a typo. I do know how to use the sed command, at least the basics; see my previous use of it ( https://news.ycombinator.com/item?id=42084984 ). But thanks, good catch.

HN "bros" (in the ugliest sense of the word "bro") showing their sick nature by viciously downvoting a perfectly innocuous comment.

Seems like many of them have nothing better to do, probably because of layoffs and statistics and linear algebra and 'predicting the next token' (hee hee) in the input, based on gigantic corpuses of data, masquerading as "AI", and many of those bros were/are worthless anyway.

As someone who really enjoys Haskell, I used to think like that. But I realized for problems like parsing, it really is just excellent.

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/

    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.

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.

> 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.

The nom crate has an RGB parser example: https://docs.rs/nom/latest/nom/#example

It’s slightly longer, but more legible.

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.

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

Reply on news.ycombinator.com