> 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?
Wow! This code looks horrible. Why don't you just accept the fact that the language is strongly typed and abolish reflection altogether?
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.
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.
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.
Breaking compatibility with .NET, which is F#'s biggest benefit is counter productive.