I believe functors are difficult rather than impossible to implment on the .NET plaform. I don't have all the details but I believe it would require lots of inlining and other gymnastics by the compiler.

Alot of would you can do with functors can be achived by using interfaces. Take a look at the implmentation of Set and Map in F#. I believe these are actually easier to use than the OCaml versions, as there's no need for types that already support IComparable there's no need to "Make" the functor. For example you can say:

1
let set = Set.of_list [1; 1; 1; 2; 3]

Cheers,
Rob

By on 2/19/2008 12:05 PM ()

I see how it's possible to do the same thing using generics, but I really think thats besides the point. I can do damn near anything in C# that I can do in F# with regards to anonymous functions and the like. But I often don't, because it would look bad and be hard to read. It logically would not flow, although I could force it in technically. I think that is the same issue here: Functors allow you to reuse code in a manner that allows me to easily reuse and 'stack' up my code, while keeping it easy to read and easy to maintain. Being able to deal with the problem one level higher makes all the difference.

I flat out reject the idea of using objects too. While .Net changes a few thing w/ regard to objects, I still find it best to try keeping side effects away if I can. Objects undmine the point a bit i think.

I wonder if enough people are interested in having functors that it could be worth it to hack together a preprocessor that does the required inlining and all. It can not be that hard to remove the functor module while replacing all of its innvocations with the filled in template. You'd miss out on reflection, but if they arent going to handle it in any release, its better than nothing.

By on 2/20/2008 1:43 PM ()

Hi,

I disagree about the useful functors, I work in a company with a huge ocaml code base and we only use them a handful of times. Netherless I understand your frustration at not having access to feature that you obviously like. I do not work on the F# compiler or even work for MS so I can't speak for them, but I believe that they are still open to suggestion and feature request. However, I think for a feature like functors you'll have to make a very strong case siting many scenarios and examples were existing F# techniques can't be used. Also I believe this year, for the F# team, is more about bug fix, tidying things up and getting everything ready for "product" version of F# rather than introducing new features, which is another reason they maybe unreciptive to functor feature request at the moment.

I think you are wrong to reject objects as being just about mutable state. In fact a large part of the OO paradigm and the FP paradigm are orthogonal. That is to say, objects need not have mutable state, in F# you can easily create "functional style" objects that are immutable and whose members create altered copies of the object rather than updating internal state (rather like .NET's string class). Expert F# has some excelent marterial on this subject in Chapter 6 "Working with Objects" and Chapter 19 "Designing Libaries".

I also think it is .NET interfaces, rather than classes, that more closely capture a functors behavior. I know they can't do everything that a functor can do, but your can really get a long way with them, especially when coupled with F# object expressions.

The idea of a preprocess to implement functor like behavior is certainly an insteresting one, I believe it will be very difficult to create a high quality and usable preprocessor, but would encorage you to experiment and post your findings to the community.

Cheers,
Rob

By on 2/21/2008 4:25 AM ()

I don't know the exact reasons.
But in case you haven't stumbled upon the workarounds with functors, this thread might be helpful.

By on 2/19/2008 11:53 AM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper