Thanks for letting me know about this library! I don’t have a use case for parsing TOML at the moment, but I’ll make sure to consider all options when it comes to this.
Would be nice if there was some feature comparison between various libraries!
I think both approaches can be abused to the point that it becomes impossible to understand the code, and I’ve seen both 
I like the “implicit” part in type classes but I also tend to think that their use should be limited. For example, I haven’t seen a better solution so far to the equality and comparison operations problem other than having the corresponding type classes.
1 Like
The String.split_on_char function in OCaml results in empty strings in the output when there’re multiple consequent spaces, so extra filtering is needed to account for this.
True, it can handle invalid inputs. A Haskell version that handles them as well wouldn’t be that different from the original example:
strSum = sum . mapMaybe readMaybe . words
But the Haskell version also can split on tab characters and line breaks as well. So there’s really no easy way to write an equivalent function.
In this example, I wanted to show the difference between the dot composition operator . and pipeline |> plus some differences in standard libraries because their focus is slightly different in both languages.
This is definitely not meant as an attack on OCaml, there’re pros and cons for both philosophies: having a barebones standard library and having a batteries-included standard library 
I don’t doubt that, no worries 
It’s just that I thought that, reading this example, a newcomer may think the OCaml code is more verbose and cumbersome while, without denying the commendable elegance of Haskell (enabled by laziness and typeclasses), the difference is IMO not that important in practice (even more so if you account for the amount of modules and extensions that must be opened in Haskell) when considering “real-life” code.
I’m not sure. I don’t mind writing String.compare when I need to, and if I need something polymorphic, I’d just put it in a functor and let the input module supply the comparison operations. The one place I actually feel the pain the most is when it comes to printing arbitrary objects. print is the one true approach to debugging ( 
), and I’d trade my kingdom for Show. There are some OK ppx solutions for this, but I still consider it a pain point.
Still, while there is a pretty big group of people who want modular implicits in OCaml (which would essentially give you function overloading), I don’t count myself among them. I’d rather swallow the pill of slight inconvenience of having a different function for every dang type than give up the extra level of explicitness and “inferablility” provided by functorized operations.
1 Like