4 ms·
As the author of language-ext [1] (functional programming library for C#) -- these suggestions are a big "YES!!!!!" from me. I assume they're doing the first o
by louthy 1y ago
As the author of language-ext [1] (functional programming library for C#) -- these suggestions are a big "YES!!!!!" from me. I assume they're doing the first one due to the way they're using static interfaces like traits (which is what I also do to support Functor, Applicative, Monad, etc. traits). Being able to refine the type-checker based on constraints would be a huuuge win. Although, I'd prefer higher-kinds :)
The second one has been a big ballache when using pattern-matching. I think the leading `.` on the patterns isn't pretty, but I'd take it over handwriting the full type name every time.
[1] https://github.com/louthy/language-ext/ https://github.com/louthy/language-ext/
- ctenb 1y agoSorry to go tangential, I was reading your blog posts following the link from your post. The monoid example is possible without static interface methods: you could use the new() constraint and have the empty constructor act as identity element. Kudos on the posts, very nice to read.
- louthy 1y agoTrue! (Although that requires an allocation) The technique works best for encoding higher-kinded traits and, as you say, Monoid doesn’t need any of that, but it was an easy way to introduce the ideas.
- chris_pie 1y agoThe second one seems very similar to the "using static" feature, but less verbose.