Related
I think of C# language compiler as a self contained black box capable of understanding text of a certain syntax and producing compiled code. On the other hand .NET framework is a massive library that contains functionality written partly by C# and partly by C++. So .NET framework depends on C# language, not the other way around.
But I cannot fit this into how LINQ works. LINQ queries are text of a particular syntax that C# compiler can understand. But to build by own LINQ provider I need to work with interfaces like IQueryable and IQueryProvider both of which are defined in System.Linq namespace of the framework.
Does that mean a functionality C# language offers is dependent on a part of .NET framework? Does C# language know about .NET framework?
.NET Framework contains of many pieces. One of the most important is CLR — Common Language Runtime. All .NET languages depend on it, C# included, because they produce IL-code which cannot be executed by machine processor. Instead, CLR executes it.
And there is also Base Class Library, BCL, which is available to use for every .NET language: C#, VB.NET, Managed C++, F#, IronRuby, you name it. I doubt it was written in C#. It doesn't depend on any features of those languages, because classes and OOP are built in CLR.
So, yes, C# language knows about .NET framework, it absolutely must know about it. Think about IEnumerable: to compile foreach into GetEnumerator(), and MoveNext() calls, C# compiler has to know that, well, IEnumerable exists. And is somewhat special.
Or think about attributes! C# compiler has the intrinsic knowledge about what methods Attribute interface provides.
But CLR itself doesn't know anything about C#. At all.
LINQ queries are text of a particular syntax that C# compiler can understand.
Well, query expressions are - but the compiler doesn't really "understand" them. It just translates them in a pretty mechanical manner. For example, take this query:
var query = from foo in bar
where foo.X > 10
select foo.Y;
That is translated into:
var query = bar.Where(foo => foo.X > 10)
.Select(foo => foo.Y);
The compiler doesn't know anything about what Where and Select mean here. They don't even have to be methods - if you had appropriate fields or properties of delegate types, the compiler would be fine with it. Basically, if the second form will compile, so will the query expression.
Most LINQ providers use extension methods to provide these methods (Where, Select, SelectMany etc). Again, they're just part of the C# language - the compiler doesn't know or care what the extension methods do.
For more details about how query expressions are translated, see part 41 of my Edulinq blog series. You may find the rest of my Edulinq series informative, too - it's basically a series of blog posts in which I reimplement LINQ to Objects, one method at a time. Again, this demonstrates that the C# compiler doesn't rely on the LINQ implementation being in the System.Linq namespace, or anything like that.
I am trying to design a library in F#. The library should be friendly for use from both F# and C#.
And this is where I'm stuck a little bit. I can make it F# friendly, or I can make it C# friendly, but the problem is how to make it friendly for both.
Here is an example. Imagine I have the following function in F#:
let compose (f: 'T -> 'TResult) (a : 'TResult -> unit) = f >> a
This is perfectly usable from F#:
let useComposeInFsharp() =
let composite = compose (fun item -> item.ToString) (fun item -> printfn "%A" item)
composite "foo"
composite "bar"
In C#, the compose function has the following signature:
FSharpFunc<T, Unit> compose<T, TResult>(FSharpFunc<T, TResult> f, FSharpFunc<TResult, Unit> a);
But of course, I don't want FSharpFunc in the signature, what I want is Func and Action instead, like this:
Action<T> compose2<T, TResult>(Func<T, TResult> f, Action<TResult> a);
To achieve this, I can create compose2 function like this:
let compose2 (f: Func<'T, 'TResult>) (a : Action<'TResult> ) =
new Action<'T>(f.Invoke >> a.Invoke)
Now, this is perfectly usable in C#:
void UseCompose2FromCs()
{
compose2((string s) => s.ToUpper(), Console.WriteLine);
}
But now we have a problem using compose2 from F#! Now I have to wrap all standard F# funs into Func and Action, like this:
let useCompose2InFsharp() =
let f = Func<_,_>(fun item -> item.ToString())
let a = Action<_>(fun item -> printfn "%A" item)
let composite2 = compose2 f a
composite2.Invoke "foo"
composite2.Invoke "bar"
The question: How can we achieve first-class experience for the library written in F# for both F# and C# users?
So far, I couldn't come up with anything better than these two approaches:
Two separate assemblies: one targeted to F# users, and the second to C# users.
One assembly but different namespaces: one for F# users, and the second for C# users.
For the first approach, I would do something like this:
Create a F# project, call it FooBarFs and compile it into FooBarFs.dll.
Target the library purely to F# users.
Hide everything unnecessary from the .fsi files.
Create another F# project, call if FooBarCs and compile it into FooFar.dll
Reuse the first F# project at the source level.
Create .fsi file which hides everything from that project.
Create .fsi file which exposes the library in C# way, using C# idioms for name, namespaces, etc.
Create wrappers that delegate to the core library, doing the conversion where necessary.
I think the second approach with the namespaces can be confusing to the users, but then you have one assembly.
The question: None of these are ideal, perhaps I am missing some kind of compiler flag/switch/attribute
or some kind of trick and there is a better way of doing this?
The question: has anyone else tried to achieve something similar and if so how did you do it?
EDIT: to clarify, the question is not only about functions and delegates but the overall experience of a C# user with an F# library. This includes namespaces, naming conventions, idioms and suchlike that are native to C#. Basically, a C# user shouldn't be able to detect that the library was authored in F#. And vice versa, an F# user should feel like dealing with a C# library.
EDIT 2:
I can see from the answers and comments so far that my question lacks the necessary depth,
perhaps mostly due to use of only one example where interoperability issues between F# and C#
arise, the issue of function values. I think this is the most obvious example and so this
led me to use it to ask the question, but by the same token gave the impression that this is
the only issue I am concerned with.
Let me provide more concrete examples. I have read through the most excellent
F# Component Design Guidelines
document (many thanks #gradbot for this!). The guidelines in the document, if used, do address
some of the issues but not all.
The document is split into two main parts: 1) guidelines for targeting F# users; and 2) guidelines for
targeting C# users. Nowhere does it even attempt to pretend that it is possible to have a uniform
approach, which exactly echoes my question: we can target F#, we can target C#, but what is the
practical solution for targeting both?
To remind, the goal is to have a library authored in F#, and which can be used idiomatically from
both F# and C# languages.
The keyword here is idiomatic. The issue is not the general interoperability where it is just possible
to use libraries in different languages.
Now to the examples, which I take straight from
F# Component Design Guidelines.
Modules+functions (F#) vs Namespaces+Types+functions
F#: Do use namespaces or modules to contain your types and modules.
The idiomatic use is to place functions in modules, e.g.:
// library
module Foo
let bar() = ...
let zoo() = ...
// Use from F#
open Foo
bar()
zoo()
C#: Do use namespaces, types and members as the primary organizational structure for your
components (as opposed to modules), for vanilla .NET APIs.
This is incompatible with the F# guideline, and the example would need
to be re-written to fit the C# users:
[<AbstractClass; Sealed>]
type Foo =
static member bar() = ...
static member zoo() = ...
By doing so though, we break the idiomatic use from F# because
we can no longer use bar and zoo without prefixing it with Foo.
Use of tuples
F#: Do use tuples when appropriate for return values.
C#: Avoid using tuples as return values in vanilla .NET APIs.
Async
F#: Do use Async for async programming at F# API boundaries.
C#: Do expose asynchronous operations using either the .NET asynchronous programming model
(BeginFoo, EndFoo), or as methods returning .NET tasks (Task), rather than as F# Async
objects.
Use of Option
F#: Consider using option values for return types instead of raising exceptions (for F#-facing code).
Consider using the TryGetValue pattern instead of returning F# option values (option) in vanilla
.NET APIs, and prefer method overloading over taking F# option values as arguments.
Discriminated unions
F#: Do use discriminated unions as an alternative to class hierarchies for creating tree-structured data
C#: no specific guidelines for this, but the concept of discriminated unions is foreign to C#
Curried functions
F#: curried functions are idiomatic for F#
C#: Do not use currying of parameters in vanilla .NET APIs.
Checking for null values
F#: this is not idiomatic for F#
C#: Consider checking for null values on vanilla .NET API boundaries.
Use of F# types list, map, set, etc
F#: it is idiomatic to use these in F#
C#: Consider using the .NET collection interface types IEnumerable and IDictionary
for parameters and return values in vanilla .NET APIs. (i.e. do not use F# list, map, set)
Function types (the obvious one)
F#: use of F# functions as values is idiomatic for F#, obviously
C#: Do use .NET delegate types in preference to F# function types in vanilla .NET APIs.
I think these should be sufficient to demonstrate the nature of my question.
Incidentally, the guidelines also have a partial answer:
... a common implementation strategy when developing higher-order
methods for vanilla .NET libraries is to author all the implementation using F# function types, and
then create the public API using delegates as a thin façade atop the actual F# implementation.
To summarise.
There is one definite answer: there are no compiler tricks that I missed.
As per the guidelines doc, it seems that authoring for F# first and then creating
a facade wrapper for .NET is a reasonable strategy.
The question then remains regarding the practical implementation of this:
Separate assemblies? or
Different namespaces?
If my interpretation is correct, Tomas suggests that using separate namespaces should
be sufficient, and should be an acceptable solution.
I think I will agree with that given that the choice of namespaces is such that it
does not surprise or confuse the .NET/C# users, which means that the namespace
for them should probably look like it is the primary namespace for them. The
F# users will have to take the burden of choosing F#-specific namespace.
For example:
FSharp.Foo.Bar -> namespace for F# facing the library
Foo.Bar -> namespace for .NET wrapper, idiomatic for C#
Daniel already explained how to define a C#-friendly version of the F# function that you wrote, so I'll add some higher-level comments. First of all, you should read the F# Component Design Guidelines (referenced already by gradbot). This is a document that explains how to design F# and .NET libraries using F# and it should answer many of your questions.
When using F#, there are basically two kinds of libraries you can write:
F# library is designed to be used only from F#, so it's public interface is written in a functional style (using F# function types, tuples, discriminated unions etc.)
.NET library is designed to be used from any .NET language (including C# and F#) and it typically follows .NET object-oriented style. This means that you'll expose most of the functionality as classes with method (and sometimes extension methods or static methods, but mostly the code should be written in the OO design).
In your question, you're asking how to expose function composition as a .NET library, but I think that functions like your compose are too low level concepts from the .NET library point of view. You can expose them as methods working with Func and Action, but that probably isn't how you would design a normal .NET library in the first place (perhaps you'd use the Builder pattern instead or something like that).
In some cases (i.e. when designing numerical libraries that do not really fit well with the .NET library style), it makes a good sense to design a library that mixes both F# and .NET styles in a single library. The best way to do this is to have normal F# (or normal .NET) API and then provide wrappers for natural use in the other style. The wrappers can be in a separate namespace (like MyLibrary.FSharp and MyLibrary).
In your example, you could leave the F# implementation in MyLibrary.FSharp and then add .NET (C#-friendly) wrappers (similar to code that Daniel posted) in the MyLibrary namespace as static method of some class. But again, .NET library would probably have more specific API than function composition.
You only have to wrap function values (partially-applied functions, etc) with Func or Action, the rest are converted automatically. For example:
type A(arg) =
member x.Invoke(f: Func<_,_>) = f.Invoke(arg)
let a = A(1)
a.Invoke(fun i -> i + 1)
So it makes sense to use Func/Action where applicable. Does this eliminate your concerns? I think your proposed solutions are overly-complicated. You can write your entire library in F# and use it pain-free from F# and C# (I do it all the time).
Also, F# is more flexible than C# in terms of interoperability so it's generally best to follow traditional .NET style when this is a concern.
EDIT
The work required to make two public interfaces in separate namespaces, I think, is only warranted when they are complementary or the F# functionality is not usable from C# (such as inlined functions, which depend on F#-specific metadata).
Taking your points in turn:
Module + let bindings and constructor-less type + static members appear exactly the same in C#, so go with modules if you can. You can use CompiledNameAttribute to give members C#-friendly names.
I may be wrong, but my guess is that the Component Guidelines were written prior to System.Tuple being added to the framework. (In earlier versions F# defined it's own tuple type.) It's since become more acceptable to use Tuple in a public interface for trivial types.
This is where I think you have do things the C# way because F# plays well with Task but C# doesn't play well with Async. You can use async internally then call Async.StartAsTask before returning from a public method.
Embrace of null may be the single biggest drawback when developing an API for use from C#. In the past, I tried all kinds of tricks to avoid considering null in internal F# code but, in the end, it was best to mark types with public constructors with [<AllowNullLiteral>] and check args for null. It's no worse than C# in this respect.
Discriminated unions are generally compiled to class hierarchies but always have a relatively friendly representation in C#. I would say, mark them with [<AllowNullLiteral>] and use them.
Curried functions produce function values, which shouldn't be used.
I found it was better to embrace null than to depend on it being caught at the public interface and ignore it internally. YMMV.
It makes a lot of sense to use list/map/set internally. They can all be exposed through the public interface as IEnumerable<_>. Also, seq, dict, and Seq.readonly are frequently useful.
See #6.
Which strategy you take depends on the type and size of your library but, in my experience, finding the sweet spot between F# and C# required less work—in the long run—than creating separate APIs.
Although it probably would be an overkill, you could consider writing an application using Mono.Cecil (it has awesome support on the mailing list) that would automate the conversion on the IL level. For example, you implement your assembly in F#, using the F#-style public API, then the tool would generate a C#-friendly wrapper over it.
For instance, in F# you would obviously use option<'T> (None, specifically) instead of using null like in C#. Writing a wrapper generator for this scenario should be fairly easy: the wrapper method would invoke the original method: if it's return value was Some x, then return x, otherwise return null.
You would need to handle the case when T is a value type, i.e. non-nullable; you would have to wrap the return value of the wrapper method into Nullable<T>, which makes it a bit painful.
Again, I'm quite certain that it would pay off to write such a tool in your scenario, maybe except if you'll be working on this such library (usable seamlessly from F# and C# both) regularly. In any case, I think it would be an interesting experiment, one that I might even explore sometime.
Draft F# Component Design Guidelines
(August 2010)
Overview This document looks at some of the issues related to F# component design and coding. In particular, it covers:
Guidelines for designing “vanilla” .NET libraries for use from any .NET language.
Guidelines for F#-to-F# libraries and F# implementation code.
Suggestions on coding conventions for F# implementation code
My professor asked us this question: What are the differences between a C#(.Net) Compiler and Java Compiler Technologies?
Both the Java and C# compilers compile to an "machine code" for an intermediate virtual machine that is independent of the ultimate execution platform; the JVM and CLR respectively.
JVM was originally designed solely to support Java. While it is possible to compile languages other than Java to run on a JVM, there are aspects of its design that are not entirely suited to certain classes of language. By contrast, the CLR and its instruction set were designed from day one to support a range of languages.
Another difference is in the way that JIT compilation works. According to Wikipedia, CLR is designed to run fully compiled code, so (presumably) the CLR's JIT compiler must eagerly compile the entire application before starting. (I also gather that you can compile the bytecodes to native code ahead of time.) By contrast, the Hotspot JVMs use true "just in time" compilation. Bytecode methods are initially executed by the JVM using a bytecode interpreter, which also gathers trace information about execution paths taken within the method. Those methods that are executed a number of times then get compiled to native code by the JIT compiler, using the captured trace information to help in the code optimization. This allows the native code to be optimized for the actual execution platform and even for the behaviour of the current execution of the application.
Of course, the C# and Java languages have many significant differences, and the corresponding compilers are different because of the need to handle these linguistic differences. For example, some C# compilers do more type inferencing ... because the corresponding C# language version relies more on inferred types. (And note that both the Java and C# languages have evolved over time.)
In terms of compiler, the largest difference I can think of (except the obvious "inputs" and "outputs") is the generics implementation, since both have generics, but very different (type erasure vs runtime-assisted). The boxing model is obviously different, but I'm not sure that is huge for the compiler.
The are obvious difference in features in terms of anonymous methods, anonymous inner classes, lambdas, delegates, etc but that is hard to compare 1:1. Ultimately, though, only your professor knows the answer he is looking for (and all due respect to professors, but don't necessarily be surprised if his answer is a year-or-more out of date with the bleeding edge).
One difference is that the C# compiler has some type inferencing capabilities that a Java compiler wouldn't have (although Java 7 may change this). As a simple example, in Java you have to type Map<String, List<String>> anagrams = new HashMap<String, List<String>>(); while in C# you can use var anagrams = new HashMap<String, List<String>>(); (although you can create very large, complex expressions in C# without ever having to name a type).
Another difference is that the C# compiler can create expression trees, enabling you to pass descriptions of a function to another function. For example, (Func<int,int>) x => x * 2 is a function that takes an int and doubles it, while (Expression<Func<int,int>>) x => x * 2 is a datastructure that describes a function that takes an int and doubles it. You can take this description and compile it into a function (to run locally) or translate it into SQL (to run as part of a database query).
http://www.scribd.com/doc/6256795/Comparison-Between-CLR-and-JVM
i think this will give you an basic idea
Is LINQ a new feature in .NET 4.0, unsupported in older versions like .NET 3.5? What is it useful for? It seems to be able to build Expression Trees. What is an Expression Tree, actually? Is LINQ able to extract info like class, method and field from a C# file?
Can someone provide me a working piece of code to demonstrate what LINQ can do?
Linq was added in .Net 3.5 (and added to the c# 3.0 compiler as well as in slightly limited form to the VB.net compiler in the same release)
In is language integrated query, though it covers many complex additions to both the language and the runtime in order to achieve this which are useful in and of themselves.
The Expression functionality is simply put the ability for a program, at runtime, inspect the abstract syntax of certain code constructs passed around. These are called lambdas. And are, in essence a way of writing anonymous functions more easily whilst making runtime introspection of their structure easier.
The 'SQL like' functionality Linq is most closely associated with (though by no means the only one) is called Linq to Sql where by something like this:
from f in Foo where s.Blah == "wibble" select f.Wobble;
is compiled into a representation of this query, rather than simply code to execute the query. The part that makes it linq to sql is the 'backend' which converts it into sql. For this the expression is translated into sql server statements to execute the query against a linked database with mapping from rows to .net objects and conversion of the c# logic into equivalent where clauses. You could apply exactly the same code if Foo was a collection of plain .net objects (at which point it is "Linq to objects") the conversion of the expression would then be to straight .Net code.
The lambda above written in the language integrated way is actually the equivalent of:
Foo.Where(f => f.Blah == "wibble).Select(f => f.Wobble);
Where Foo is a typed collection. For databases classes are synthesized to represent the values in the database to allow this to both compile, and to allow round tripping values from the sql areas to the .net areas and vice versa.
The critical aspect of the Language Integrated part of Linq is that the resulting language constructs are first class parts of the resulting code. Rather than simply resulting in a function they provide the way the function was constructed (as an expression) so that other aspects of the program can manipulate it.
Consumers of this functionality may simply chose to run it (execute the function which the lambda is compiled to) or to ask for the expression which describes it and then do something different with it.
Many aspects of what makes this possible are placed under the "Linq" banner despite not really being Linq themsleves.
For example anonymous types are required for easy use of projection (choosing a subset of the possible properties) but anonymous types can be used outside of Linq as well.
Linq, especially via the lambdas (which make writing anonymous delegates very lightweight in terms of syntax) has lead to an increase in the functional capabilities of c#. this is reinforced by the extension methods on IEnumerable<T> like Select(), corresponding to map in many function languages and Where() corresponding to filter. Like the anonymous types this is not in and of itself "Linq" though is viewed by many as a strongly beneficial effect on c# development (this is not a universal view but is widely held).
For an introduction to Linq from microsoft read this article
For an introduction to how to use Linq-to-Sql in Visual Studio see this series from Scott Guthrie
For a guide to how you can use linq to make plain c# easier when using collections read this article
Expressions are a more advanced topic, and understanding of them is entirely unecessary to use linq, though certain 'tricks' are possible using them.
In general you would care about Expressions only if you were attempting to write linq providers which is code to take an expression rather than just a function and use that to do something other than what the plain function would do, like talk to an external data source.
Here are some Linq Provider examples
A multi part guide to implementing your own provider
The MDSN documentation for the namespace
Other uses would be when you wish to get some meta data about what the internals of the function is doing, perhaps then compiling the expression (resulting in a delegate which will allow you to execute the expression as a function) and doing something with it or just looking at the metadata of the objects to do reflective code which is compile time verified as this answer shows.
One area of this question that hasn't been covered yet is expression trees. There is a really good article on expression trees (and lambda expression) available here.
The other important thing to bring up about expression trees is that by building an expression tree to define what you are going to do, you don't have to actually do anything. I am referring to deferred execution.
//this code will only build the expression tree
var itemsInStock = from item in warehouse.Items
where item.Quantity > 0;
// this code will cause the actual execution
Console.WriteLine("Items in stock: {0}", itemsInStock.Count());
LINQ was introduced with .NET 3.5. This site has a lot of examples.
System.Linq.Expressions is for hand building (or machine generating) expression trees. I have a feeling that given the complexity of building more complicated functionality that this namespace is under used. However it is exceedingly powerful. For instance one of my co workers recently implemented an expression tree that can auto scale any LINQ to SQL object using a cumultive density function. Every column gets its own tree that gets compiled so its fast. I have been building a specialized compiler that uses them extensively to implement basic functionality as well as glue the rest of the generated code together.
Please see this blog post for more information and ideas.
LINQ is a .NET 3.5 feature with built-in language support from C# 3.0 and Visual Basic 2008. There are plenty of examples on MSDN.
Is there any C#/F# performance comparison available on web to show proper usage of new F# language?
Natural F# code (e.g. functional/immutable) is slower than natural (imperative/mutable object-oriented) C# code. However, this kind of F# is much shorter than usual C# code.
Obviously, there is a trade-off.
On the other hand, you can, in most cases, achieve performance of F# code equal to performance of C# code. This will usually require coding in imperative or mutable object-oriented style, profile and remove bottlenecks. You use that same tools that you would otherwise use in C#: e.g. .Net reflector and a profiler.
That having said, it pays to be aware of some high-productivity constructs in F# that decrease performance. In my experience I have seen the following cases:
references (vs. class instance variables), only in code executed billions of times
F# comparison (<=) vs. System.Collections.Generic.Comparer, for example in binary search or sort
tail calls -- only in certain cases that cannot be optimized by the compiler or .Net runtime. As noted in the comments, depends on the .Net runtime.
F# sequences are twice slower than LINQ. This is due to references and the use of functions in F# library to implement translation of seq<_>. This is easily fixable, as you might replace the Seq module, by one with same signatures that uses Linq, PLinq or DryadLinq.
Tuples, F# tuple is a class sorted on the heap. In some case, e.g. a int*int tuple it might pay to use a struct.
Allocations, it's worth remembering that a closure is a class, created with the new operator, which remembers the accessed variables. It might be worth to "lift" the closure out, or replaced it with a function that explicitly takes the accessed variables as arguments.
Try using inline to improve performance, especially for generic code.
My experience is to code in F# first and optimize only the parts that matter. In certain cases, it might be easier to write the slow functions in C# rather that to try to tweak F#. However, from programmer efficiency point of view makes sense to start/prototype in F# then profile, disassemble and optimize.
Bottom line is, your F# code might end-up slower than C# because of program design decisions, but ultimately efficiency can be obtained.
See these questions that I asked recently:
Is a program F# any more efficient (execution-wise) than C#?
How can I use functional programming in the real world?
Is it possible that F# will be optimized more than other .Net languages in the future?
Here are a few links on (or related to) this topic:
http://cs.hubfs.net/forums/thread/3207.aspx
http://strangelights.com/blog/archive/2007/06/17/1588.aspx
http://khigia.wordpress.com/2008/03/30/ocaml-vs-f-for-big-integer-surprising-performance-test/
http://cs.hubfs.net/blogs/f_team/archive/2006/08/15/506.aspx
http://blogs.msdn.com/jomo_fisher/
What I seem to remember from another post on Robert Pickering's blog (or was it Scott Hanselman?) that in the end, because both are sitting on the same framework, you can get the same performance from both, but you sometimes have to 'twist' the natural expression of the language to do so. In the example I recall, he had to twist F# to get comparable performance with C#...