3 ms·

Feel free to pilfer some ideas from my own take on a similar lib for C#. https://github.com/danstone/lambit https://github.com/danstone/lambit - includes some b

Feel free to pilfer some ideas from my own take on a similar lib for C#. https://github.com/danstone/lambit https://github.com/danstone/lambit - includes some basic pattern matching support for example. This sort of library is kind of necessary I feel for things like poor tuple support at least. I'm not entirely sure about the casing conventions. I mostly code in clojure/haskell/f# but 'when in rome'. Its likely the sort of thing that will turn off a lot of stubborn developers.

louthy 12y ago
Yeah I've implemented a similar pattern matching library before (not public though). I always felt the syntax to be a bit 'bulky' because there were always two lambdas, one for the predicate and one for the handler. I like your take on list matching though, I think that's excellent and much more usable. Not 100% sure how it could be adapted in a general way to the C# Tuple though; because Tuple<A,B> is a different type to Tuple<A,B,C>. So you could only ever match on one type (if you don't take the bulky predicate route that is).
- dstone16321 12y ago
  List matching tends to be fairly useful even its very limited form in my lib. Its basically arity match + de-structure. It doesn't nest like full fat pattern matching. I don't see how tuple matching is as useful (over your 'With' fn or my 'Apply') unless it can nest, especially with matches on union types. e.g (Maybe a, b) | (Nothing, b) Basically I feel like such a thing is going to be very hard in C# to achieve with any sort of usable api. I personally took the route of the api being more important than whether any sort of decent abstraction is actually there behind the scenes - I didn't mind writing 100's lines of boilerplate to get the result and behaviour I wanted. Its great to see more functional support for C# from the community and I look forward to using your lib in the future!

louthy 12y ago

Yeah I've implemented a similar pattern matching library before (not public though). I always felt the syntax to be a bit 'bulky' because there were always two lambdas, one for the predicate and one for the handler. I like your take on list matching though, I think that's excellent and much more usable. Not 100% sure how it could be adapted in a general way to the C# Tuple though; because Tuple<A,B> is a different type to Tuple<A,B,C>. So you could only ever match on one type (if you don't take the bulky predicate route that is).

dstone16321 12y ago
List matching tends to be fairly useful even its very limited form in my lib. Its basically arity match + de-structure. It doesn't nest like full fat pattern matching. I don't see how tuple matching is as useful (over your 'With' fn or my 'Apply') unless it can nest, especially with matches on union types. e.g (Maybe a, b) | (Nothing, b) Basically I feel like such a thing is going to be very hard in C# to achieve with any sort of usable api. I personally took the route of the api being more important than whether any sort of decent abstraction is actually there behind the scenes - I didn't mind writing 100's lines of boilerplate to get the result and behaviour I wanted. Its great to see more functional support for C# from the community and I look forward to using your lib in the future!