3 ms·
I agree that even the CLR itself needs improvements for functional programming. Besides the tail calls link you gave, there is also (according to MS) inability
by sixbrx 13y ago
I agree that even the CLR itself needs improvements for functional programming. Besides the tail calls link you gave, there is also (according to MS) inability to implement type classes because of CLR changes that would be necessary: https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2228766-add-higher-order-generics-to-f-type-classes https://visualstudio.uservoice.com/forums/121579-visual-stud...
I think F# would benefit a lot from either ML's module system or at least type classes as a simpler case. As it is it can only (directly) do single virtual dispatch (mainstream OO dispatch), which is pretty limiting and makes it more of a C# with different syntax.
- profquail 13y agoF# could potentially get a module system in the future (a la OCaml or SML). I've put together some proof-of-concept code to show how modules could be implemented on top of the existing .NET type system, so at this point it's just a matter of refining that representation and then implementing that in the language/compiler.
- Hakeashar 13y agoI'd love to see some kind of typeclass support in F#... In the meantime, honest question: what are modules in OCaml? I tried to read up on it online, but my understanding of the topic is still murky. Regular modules don't really seem that interesting (they look like modules and/or types/classes in F#), parametrized modules seem to be something that is missing in F#. Second question, do you have that proof of concept code laying somewhere around? I'm just curious how it would look in F#...
- profquail 13y agoYes, F# is missing parameterized modules ("functors"); these are simply modules which are parameterized by other modules in the same way .NET generics (for example) allow you to parameterize one type by another type. The reason this would be nice to have in F# is that, while the CLR's generics are excellent in general, there are some things that can't be expressed using the CLR's type constraints. Supporting functors in F# would provide a nice way to work around this and allow you to write code which is more generic. Here's my proof-of-concept code. I'll warn you now though -- it looks quite messy, because the goal was to show that functors could be supported on top of the existing .NET type system. If functors are ever added to the F# language, the syntax will be much, much cleaner. https://github.com/jack-pappas/experimental-functors https://github.com/jack-pappas/experimental-functors
- sixbrx 13y agoThis is great news (thank you for doing it)! Especially that it doesn't require changes within the CLR which seems to be a death sentence for proposals. I've been teetering with trying F#, and a proper ML-like module system may tip the balance in its favor for me, I'm sure I'm not alone in that. It just didn't seem like a "real" ML without the module system or at least type classes.
- UK-AL 13y agoIn C# you can do double dispatch, or you talking about something else here?
- sixbrx 13y agoI wasn't aware that you could do double dispatch without encoding it yourself with something like the visitor pattern, is that what you meant?
- UK-AL 13y agoIs this what your looking for http://blogs.msdn.com/b/shawnhar/archive/2011/04/05/visitor-and-multiple-dispatch-via-c-dynamic.aspx?Redirected=true http://blogs.msdn.com/b/shawnhar/archive/2011/04/05/visitor-... Double dispatch without visitor pattern, using dynamic type.
- sixbrx 13y agoThat's a neat feature! So my aside about single dispatch was misplaced. What I'm really after though is somewhat the opposite, which is static dispatch so that the functions called are known at compile time and can be optimized that way (I do a lot of numerics coding), so avoiding any method resolution lookup and even the vtable jumps and resulting target mispredicts. That's a nice feature of both type classes and ML's module system as usually implemented in functional languages. One really nice thing is they can also typically "dispatch" statically on return types of functions too which makes for some neat patterns as well using type inference. Anyway thanks for pointing to that. It definitely beats the visitor pattern as is necessary in Java. And I assume it would work for more than two parameters too, which is another advantage over standard visitor.