
Generic Programming Made Easy in F# - tamizh88
https://www.demystifyfp.com/fsharp/blog/generic-programming-made-easy
======
vittore
Read it twice, still not sure why simple type/tuple/record pattern matching
was not enough. ([https://docs.microsoft.com/en-us/dotnet/fsharp/language-
refe...](https://docs.microsoft.com/en-us/dotnet/fsharp/language-
reference/pattern-matching)). Also active pattern matching could've solve
exotic cases, if any ([https://docs.microsoft.com/en-
us/dotnet/fsharp/language-refe...](https://docs.microsoft.com/en-
us/dotnet/fsharp/language-reference/active-patterns))

~~~
vorotato
saaame... A solution looking for a problem perhaps?

------
burgerdev
> if isGenTypeOf typedefof<_ option> then

Wow! This code looks horrible. Why don't you just accept the fact that the
language is strongly typed and abolish reflection altogether?

~~~
burgerdev
I apologize for the tone of my comment, but still think that ML is not
supposed to be written like that.

~~~
bunderbunder
Agreed for ML. However, F# is not exactly ML. It lives on top of, and has to
interoperate with, the existing .NET ecosystem.

That means, for example, that a lot of the datatypes you'll end up dealing
with are object-oriented. Those can be difficult to work with in a generic way
without resorting to reflection.

~~~
burgerdev
Sounds a bit like the Scala story: could be a really nice language, but the
bagagge ... :)

~~~
bunderbunder
It is a really nice language. Being able to interoperate with .NET is a
strength, not a weakness. It's quite principled in its design, it's just that
some of its design principles are pragmatic ones.

Concrete example: It doesn't have typeclasses. This was a deliberate and
thoughtful move. The designers haven't been able to figure out how to
implement type classes in a way that wouldn't interact poorly with the rest of
the .NET ecosystem, so they've opted to keep them out rather than introducing
a hacky implementation. Contrast this with Scala, where it's very easy to
accidentally break compatibility with Java code when you're working with
traits.

~~~
catnaroek
> Concrete example: It doesn't have typeclasses.

It's not like type classes are themselves suuuper-principled.

> Being able to interoperate with .NET is a strength, not a weakness.

Being able to interoperate with .NET is a good thing. Letting the .NET object
model permeate the whole language's type structure is less of a good thing (to
put it mildly). OCaml did the right thing w.r.t. objects: You can use objects
if you so wish, but the language doesn't ram them down your throat.

~~~
tueo23094
F# and OCaml are different languages with different goals. It should come as
no surprise there are different sacrifices between the languages.

Breaking compatibility with .NET, which is F#'s biggest benefit is counter
productive.

~~~
catnaroek
My suggestion wouldn't “break compatibility” with .NET any more than, say,
C++/CLI (or whatever it is called nowadays) does.

------
vorotato
I think there is a frequent problem where blog posts are written by people who
went down a rabbit hole they maybe shouldn't even be down.

