Earlier quoted context omitted.
Evan also wants to prevent people from making packages that solve certain types of problems so that he'll be able to make a better package in the future without needing to worry people might not want to switch because of backwards compatibility. I think that's entirely his right, but I'm skeptical it'll work.
Clojure and Common Lisp managed to have super stable community-built libraries. I'm not entirely sure what contributed to this (ie did this happen because of a stable core? Did this happen because lisps are somehow naturally conducive to stable extension?) but it's possible to have this happen without preventing community built-libraries.. :<
> Of all the changes in 0.19, this is the one that most hurt my code: I have parser combinator library, and used just two custom operators, for the very reasons that Evan points out in at the top.
> Now I learn that elm/parser can, and does, define two operators for parsing, for the same reasons my library had done so. There are indeed times when custom embedded languages with custom operators are worth the mental effort on the programming staff. Parsing is one of them, which Evan acknowledges, and indeed uses in elm/parser.
> However, it is not realistic to assume that elm/parser will become the only parsing package we ever need. For one, it only works on String. Parsing over byte arrays is quite common, (and what mine did). Even if elm/parse had been parameterized on the stream type - there are still differing implementation and functionality tradeoffs in parsers (backtracking, error tracking, error recovery, etc..) that make different parser libraries useful even they support the same stream type.