Hacker News Reader

Comment by steego | Hacker News Reader

Funny I come across this today. Only yesterday did I start turning some of my helper functions and extension methods into a little NuGet library. It's amazing how much overlap there is between your library and mine, though I'm probably going to steal some of your tricks. :)

While I do have an Option type with all the relevant LINQ operators defined, I've resorted to using Nullable<T> for all string parsing functions that return primitives as Nullable is a type that's actually supported databases. For any nullable, I can use a nullableVar.DefaultTo(defaultValue) to convert it to a non-nullable primitive type. Personally, I don't find Option types in C# all that compelling because the pattern matching mechanism doesn't compel you to handle all cases like F#.

All in all, it looks like an interesting library.

Thanks for posting!

View on HN

Heh, that's really interesting! Do you have a link to your work?

> Personally, I don't find Option types in C# all that compelling because the pattern matching mechanism doesn't compel you to handle all cases like F#.

In my library you are compelled. You must provide both a Some and None handler, even on the fluent variant. That was one aspect I absolutely wanted to nail after doing a reasonable amount of F# work recently.

The only exception to that is you can ignore the Some branch, and just handle failure. The Some branch then just uses an identity function behind the scenes. So you're still compelled to deal with the failure case, which is where I feel most of the C# null carnage comes from.

> Heh, that's really interesting! Do you have a link to your work?

I do and I don't. I actually wrote a lot of these things in VB.NET 4-5 years ago and I've recently returned to the .NET world, so I'm in the process of converting it to C#.

There's a ton I haven't converted yet (Option types, lazy thunks that use LINQ, Parser monads, LINQ Trees, etc.), and there's a ton I'm going to let die out. :)

Here's a work-in-progress: https://github.com/steego/Steego.NET

> There's a ton I haven't converted yet (Option types, lazy thunks that use LINQ, Parser monads, LINQ Trees, etc.),

ahem https://github.com/louthy/csharp-monad ;-)

> Here's a work-in-progress:

Cool, I'll take a look.

> ahem https://github.com/louthy/csharp-monad ;-)

Very nice! You may save me a bunch of work yet. We should get some of your stuff into NuGet packages so you can spread the love. I saw on Twitter that Miguel de Icaza approves of your library. :)

BTW, I just pushed up my little Tree library to my repo. Feel free to incorporate and change it however if you like it. https://github.com/steego/Steego.NET/tree/master/Steego.Tree...

> I saw on Twitter that Miguel de Icaza approves of your library. :)

That's awesome! Thanks for sharing. I wouldn't even know how to get something onto NuGet. I guess my weekend project might have to become a bit more serious ;) Time to do some research.

EDIT: research done... https://www.nuget.org/packages/LanguageExt/0.0.1-beta

It's a good idea but i think in reality people will be lazy, not know what to do, and just throw their own NullPointerException inside the None-handler. And then we are full circle back on square one.

It's like checked exceptions in java. Sounds good on paper but in practice this happens: You are in the middle of just bursting out code to quickly get a response from a local rest api and you hit compile to suddenly get a whole list of "NetworkException/JsonParseException/WhateverBloatException not handled". At the moment you couldn't care less and just convert everything into a RuntimeException and tada! you don't have checked exceptions anymore.

I think it might also cause unnecessary bloat when mixing code that uses the Option type and not, I've seen it happen with code contracts, either everything or nothing must be annotated. Once you start mixing you will have to add assertions before or after every call to the unannotated library.

It's great that people see the value in having these kinds of functional tools! I also put together a library that looks very similar to this, and it sure has been handy. I used it as a foundation to build some solid algebraic APIs (typesafe parser combinators based on the Brzozowski derivative and pickler combinators).

I like how the catamorphism is called "Match" rather than "Fold" (which is what Scala uses). Using named parameters whenever Match is called really does help with the readability, and they make the "case analysis" explicit.

> For any nullable, I can use a nullableVar.DefaultTo(defaultValue) to convert it to a non-nullable primitive type.

What would be the difference with "nullableVar ?? defaultValue" ?

Good point. I originally wrote it for VB.NET, though IF(nullableVar,defaultValue) would be better now...

Reply on news.ycombinator.com