3 ms·
Aha! I thoroughly enjoyed reading all that, and do hope you continue. It sounds like you're at or slightly ahead of my level of Haskell experience (I knew you'd
by losvedir 12y ago
Aha! I thoroughly enjoyed reading all that, and do hope you continue. It sounds like you're at or slightly ahead of my level of Haskell experience (I knew you'd need Eq before you did! But then the Applicative stuff was beyond me...), so this is very insightful for me as I wonder whether to try picking it up again.
"Fine. It's good enough. Moving On." made me laugh! It seems like you thought that could be refactored in a much simpler way. Not knowing (much) Racket, it didn't appear super obvious to me how. Were you alluding to a macro or something? How would you do it in Racket?
- lexi-lambda 12y agoAh, no, I probably wouldn't do it any simpler in Racket. Racket tends to de-emphasize more complicated function composition, which tends to serve it just fine. I've always adopted a somewhat pro-functional approach in my usage of the language, but even here there wouldn't really be a distinctly better way to do it. I guess I was just hoping that Haskell, being a more composition-oriented language in many ways, would have some nice built-in to do that for me.
- evincarofautumn 12y agoIn concatenative programming languages, composition is the default, and it makes point-free code much easier to write. In Factor, for example, you could write your example as: : inexact-matches ( x y -- n ) [ matches ] [ exact-matches ] 2bi - ; That is, run both “matches” and “exact-matches” on both inputs, then take the difference of the results. If Haskell had functions of multiple parameters and results, 2bi’s type would look like this: (a, b, ((a, b) -> c), ((a, b) -> d)) -> (c, d)