4 ms·

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

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

iudqnolq 5y ago
My impression is that Evan thinks a stable community built library that he doesn't like the feel of would ruin his language, so he'd rather have an unstable library he controls (because he doesn't have the bandwidth for everything). If this eventually leads to lots of stable great libraries written by Evan that would be nice, but until then it doesn't seem worth investing in. Here's what the author of a parsing library had to say > 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.

4 ms·

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

by azeirah 5y ago

iudqnolq 5y ago
My impression is that Evan thinks a stable community built library that he doesn't like the feel of would ruin his language, so he'd rather have an unstable library he controls (because he doesn't have the bandwidth for everything). If this eventually leads to lots of stable great libraries written by Evan that would be nice, but until then it doesn't seem worth investing in. Here's what the author of a parsing library had to say > 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.