Logo




Subscribe:
RSS 2.0 | Atom 1.0
Categories:

Sign In


[Giagnocavo]Michael::Write()

# Thursday, August 02, 2007
C# Frustration

C# with lambda syntax and extension methods (in lieu of compositional operators) gets us so far, but the syntax and compiler could use a bit of polish. I'll show some exact examples later, but meanwhile this picture sums up my feelings at the moment:

Notype1.png

Edited to add: Inspired by http://xkcd.com/297/

Edited to add: Just to be clear, this isn't a compiler or IDE issue: it's a spec issue (AFAIK). The C# spec simply doesn't allow certain things (like type inference from a method group).

Code | Humour
Thursday, August 02, 2007 7:39:10 PM UTC  #    Comments [7]  |  Trackback

Thursday, August 02, 2007 8:22:34 PM UTC
Is this a MS-compiler issue (Orcas Beta 2) or a mono-compiler one? You might want to let the LINQ team know about it.
Thursday, August 02, 2007 8:34:59 PM UTC
I'm really confused with all this lambda stuff lately... it's like a complete new language and
none of the books seem to explain it in normal people's language... feels like you're supposed to be
a rocket scientist to understand some of the books (and I never had this problem before :p)

Anyway, I'm guessing you don't like the fact that the editor is telling you it's wrong? :p
Thursday, August 02, 2007 8:42:38 PM UTC
Sorry I didn't make it clear; it's a C# spec issue in general -- such things are simply not allowed (hopeful note: yet!).

Taking a more-functional approach to C# (lambdas being the big syntactic benefit) can be very confusing at first. However, in some scenarios, it is much more powerful, and all C# developers would do good to learn it. You bring up an interesting point that the materials out there don't seem to be clear. I'd like to see more people adopt functional programming, and I'd like to learn what is perceived as being difficult about it.

The majority of developers I've approached seem against it. I think I've only seen 2 or 3 people's eyes light up when they get what they can do with it. I'd like to change that (although people much smarter than me have tried before...).
Thursday, August 02, 2007 11:10:46 PM UTC
I agree that some of the warnings are annoying, but inferencing the type of the local variable "add" is tricky. If I recall correctly, O'Caml can only infer the type of "add" because the "+" operator only adds integers. To add floating point numbers, you need to use a different operator. C# allows the "+" operator for many different types, so it can't do what O'Caml does.

One possible solution is to do more global inference (i.e. use information about how the variable 'add' is used to refine the type further), but this has some issues. It makes the type inference much more complicated and harder to predict for the programmer. It also wont work all the time.

What Haskell does (roughly) is define an "Num" interface that has addition and subtraction methods. A Haskell-like type inferencer would yield something like "func<T>(T, T) -> T [where T : Num]". C# would probably need a separate "Plusable" interface because there are non-numeric operations that use the "+" operator (for example, string concatenation). A potential problem here is that it's now easy to accidentally use the generic version even when you only really need integer addition; the code will end up performing unnecessary virtual method calls and integer value boxing. Then again, maybe the compiler should trust you and leave the performance-related warnings to tools like FxCop. (Also, a good cross-procedure optimizer can also help.)
Friday, August 03, 2007 11:36:02 AM UTC
Kannan, you're right that C# right now can't infer from operators because it has no way of putting a generic constraint on such a function. It's been discussed before: adding some kind of operator constraint for generics. For instance here:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=91040

I know I've seen other conversations on that but can't find them right now. But, I'll admit, this is the least important issue; I threw it in for fun.

As far as performance on those kinds of things, that's what I'd expect the platform to sort out for me. If someone writes straightforward code and it has some kind of a hidden perf hit, so much worse for the platform.
Thursday, August 09, 2007 12:03:30 AM UTC
I'm really going to put my teeth in all of this :-)
Thnx for the updated information.
Monday, August 20, 2007 9:30:23 AM UTC
Looking at the local "add", I realized that a more specific example also doesn't work.
Func<int, int, int> add = (int a, int b) => a + b; // works fine
var add2 = (int a, int b) => a + b; // CS0815

That second line should work. A lambda expression with explicitly typed arguments should have it's type inferred.
I filed a bug report here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=294156

We'll see if they give the "Specifications" excuse.
sharoz
OpenID
Please login with either your OpenID above, or your details below.
Name
E-mail
Home page

Comment (HTML not allowed)  

Enter the code shown (prevents robots):

Live Comment Preview