3 ms·

This post is seriously misguided. > The tools Haskell gives you are great at some things, but dealing with arbitrarily nested ADTs is not one of them. There's

This post is seriously misguided. > The tools Haskell gives you are great at some things, but dealing with arbitrarily nested ADTs is not one of them. There's nothing more natural in Haskell than recursion and processing of ADTs. There are dozens incredibly well-research patterns for processing just about anything under the sun. > What we wound up doing was nesting pattern matching to get at the value we wanted. The deeper the JSON nesting, the deeper our pattern matching. In my experience that works great for moderately complicated and ugly JSON messages. Tried that in Haskell, OCaml and Rust. Rust was most clunky due to the way things are represented in serde (I expect that's more performant though) but still worked nicely. Alternatively, lenses would allow for incredibly easy access to just about anywhere in any JSON document. Want to hit multiple nested targets in weird locations? No problem! > But imagine if more and more of your code is dealing with JSON. It would be nice if there were some easier way. Sadly the author skipped explaining that mythical "easier way".

thedufer 9y ago
> There's nothing more natural in Haskell than recursion and processing of ADTs. There are dozens incredibly well-research patterns for processing just about anything under the sun. MLs are widely cited as some of the best languages for implementing compilers in, and large chunks of a compiler consist of transforming various ASTs. An AST being a particularly complex recursive ADT, it seems strange to claim that's a weak point of statically-typed languages.
- emeraldd 9y ago
  The weak point he's highlighting isn't in processing the ADT itself. The problem is that there's a loss of semantic meaning about the information stored in the ADT. i.e. The ADT itself cannot dictate that the semantic structure of the information it stores is correct even though it may represent a well formed "Document"
  - GreaterFool 9y ago
    Clearly the best way to store a document is a blob of text!
steveklabnik 9y ago
I'd be interested in hearing more about your Serde experience, if you have the time.
- GreaterFool 9y ago
  There's not much to it. It works really nice and is super easy if you can deserialize to Rust's records. In most cases the code can just be generated but there's also an option to override `serializer` and `deserializer` for specific fields. So you can generate most and have one custom for instance. That's great. However, I was parsing some ugly format that doesn't deserialize cleanly: match v.as_slice() { &[Value::String(ref s), Value::Object(ref o)] if s.as_str() == "i" => { // more code here and still need to unpack x and y from o } to parse something like `["i", {"x": ..., "y": ...}]`. In Haskell you could do: case j of Array [String "i", Object o] | Just x <- HashMap.lookup "x" o, Just y <- HashMap.lookup "y" o -> // code goes here, can refer to x and y
  - steveklabnik 9y ago
    Interesting, thanks!

thedufer 9y ago

> There's nothing more natural in Haskell than recursion and processing of ADTs. There are dozens incredibly well-research patterns for processing just about anything under the sun. MLs are widely cited as some of the best languages for implementing compilers in, and large chunks of a compiler consist of transforming various ASTs. An AST being a particularly complex recursive ADT, it seems strange to claim that's a weak point of statically-typed languages.

emeraldd 9y ago
The weak point he's highlighting isn't in processing the ADT itself. The problem is that there's a loss of semantic meaning about the information stored in the ADT. i.e. The ADT itself cannot dictate that the semantic structure of the information it stores is correct even though it may represent a well formed "Document"
- GreaterFool 9y ago
  Clearly the best way to store a document is a blob of text!

steveklabnik 9y ago

I'd be interested in hearing more about your Serde experience, if you have the time.

GreaterFool 9y ago
There's not much to it. It works really nice and is super easy if you can deserialize to Rust's records. In most cases the code can just be generated but there's also an option to override `serializer` and `deserializer` for specific fields. So you can generate most and have one custom for instance. That's great. However, I was parsing some ugly format that doesn't deserialize cleanly: match v.as_slice() { &[Value::String(ref s), Value::Object(ref o)] if s.as_str() == "i" => { // more code here and still need to unpack x and y from o } to parse something like `["i", {"x": ..., "y": ...}]`. In Haskell you could do: case j of Array [String "i", Object o] | Just x <- HashMap.lookup "x" o, Just y <- HashMap.lookup "y" o -> // code goes here, can refer to x and y
- steveklabnik 9y ago
  Interesting, thanks!