Home >

Is lambda a syntatic sugar, or Turkish delight?

1. January 2009

We had been discussing on twitter+gtalk if lambdas are syntatic sugar or not. According to wikipedia, a syntatic sugar is a term coined by Peter J. Landin for additions to the syntax of a computer language that do not affect its functionality but make it "sweeter" for humans to use. Based on this description, what I see is that: We could build up an expression tree with a bunch of method calls before c# 3.0, but now we have an easier way of building it. It was even possible to build an expression tree runtime (take a look at db4o native queries and mono project). Moreover, lambdas aren’t just for expressions but also they can be converted into delegates.

Let’s do some demonstration now:

Action<MyClass> myAction=x=>x.Increment();

This piece of code is translated into following code

private static void Main(string[] args)
    Action<MyClass> myAction = (CS$<>9__CachedAnonymousMethodDelegate1 != null) ? CS$<>9__CachedAnonymousMethodDelegate1 : (CS$<>9__CachedAnonymousMethodDelegate1 = new Action<MyClass>(Program.<Main>b__0));

(Please note that our lambda has been converted into another ordinary method at compile time)
This code could have been written using ordinary C# syntax.

As you know, Lambas can also be converted into an expression depending on the context:

Expression<Action<MyClass>> myExpression = x => x.Increment();

This one, for example, will be translated into

private static void Main(string[] args)
    ParameterExpression CS$0$0000;
    Expression<Action<MyClass>> myExpression = Expression.Lambda<Action<MyClass>>(Expression.Call(CS$0$0000 = Expression.Parameter(typeof(MyClass), "x"), (MethodInfo) methodof(MyClass.Increment), new Expression[0]), new ParameterExpression[] { CS$0$0000 });

Now instead of into method/delegate, lambda has been converted into an expression, which can be done using an existing C# syntax.
One thing to note, Lambda itself has nothing to do with expressions. They can be converted into Expressions and then it is a piece of code that make something with those expressions (means that expressions can be interpreted by some providers) but it is a _short cut_ of doing it.

After those examples, one of my friends told that if we are talking about IL/CLR syntatical sugars, then they would agree. We can also extend this statement into “any programming language other than assembly (or basically 101001000s) is a syntatical sugar.” I would have agreed if I hadn’t known the definition of programming language.

For me, the syntatical sugars of C# language are the followings:
  1. The using statement
  2. The var keyword
  3. Lambdas
  4. Anonymous methods
  5. The dynamic keyword
  6. Automatic properties
  7. Object/Collection initializers

On the other hand, Generics, for example, is not a syntatical sugar. It doesn’t fall into another code within the same language. I am not sure about if this definition is valid, but this is the way I think it.

Just my 2 ykrs, I am trying to draw the boundaries of a syntatical sugar, and this post, hopefuly, will serve this purpose.

kick it on DotNetKicks.com


1/2/2009 10:19:05 AM #
It looks like your definition of syntactic sugar is "was it added without any modification to the CLR spec?"
Following on from the wikipedia article, you've defined your "core" to be IL. By that definition I agree with you.

Myself, I draw a distinction. If using() was deprecated tomorrow, it would be relatively straightforward to modify our codebases to use try/finally accordingly. If the lambda syntax was deprecated tomorrow, then Linq2SQL, Fluent NHibernate and other libraries would become -useless-. NOBODY would be replacing their c => c.FirstName fragments with the awful code explosion that is necessary - they would go back to using libraries that did not rely on lambdas.

And lets look at automated properties. They have interesting behaviour - they allow me to define a property backed by a field that cannot be accessed directly. If they really are syntactic sugar, could you please show me the code that does the equivalent?

Finally, would you have said that string literals are syntactic sugar? Wikipedia says they are..
1/2/2009 3:45:27 PM #
As long as it is useful, I don't care if its called syntactic sugar or whatever.
1/2/2009 7:40:57 PM #
@Paul Batum
I have to agree with you on that, if lambdas didn't exist, it would be really annoying to do that, eventhough it is hard, though, there are libraries to analyze them runtime(as in db4o native query analyzer).

The difference in our point of view is probably the description, it seems. I have to agree that lambda's may not be a real syntatic sugar but the thing is lambda's are just part of the expression ceramony. You're evaluting it in expression context. The same lambdas can be used as a replacement to some anonymous delegate stuff.

I agree on its usefulness, and probably nobody cares if it's called syntatical sugar or Turkish delight. We just use it!
1/2/2009 7:50:33 PM #
And on the automatic properties, I don't think it's as important as lambdas. As most of the other .net 3.0 properties, they are the just for linq/expression stuff. Anonymous types are an example.
Their fields are generated at compile time, nobody could access it, but via reflection, it's still possible to access them. You can do this by yourself using private fields, if I didn't want to access private field in my own class, then I wouldn't.

I see string literals as the part of the language. Wikipedia's example brings the discussion to "syntatical sugar on assembly" thing. They're even saying that C++ OOP is a syntatical sugar. Yes it is, but over assembly language, not on C++ itself.
1/6/2009 2:42:47 PM #
I agree, automated properties are not nearly as important as lambdas. I was just pointing them out because they were in your list of syntactic sugar, and yet they allow you to do something that cannot otherwise be done (have a property backed by an innaccessible field).
1/7/2009 8:45:54 AM #
Paul, you're right about the inaccessible field so you can create readonly stuff, but part of the purpose of properties is to wrap lazy evaluation or perhaps trigger some events or something therein.  Auto properties remove that benefit.  So yes, you get properties, with optionally only 'get' or 'set' exposed or both, but, that's not really all that significant considering all you give up with autoproperties.  The only thing I can think you might make a policy of using them for is so that they are placeholders for when you go back and stick in some observer delegate calls or whatever later on.  For example, the kind of thing that you see when you generate 'Data Bindable' classes using xsd.exe.
1/7/2009 8:51:25 AM #
Readonly wouldn't serve that purpose, because those private fields are not readonly. and agree on other parts.

@Paul Batum
It all depends on where you're looking from. Since i am the owner of the class, i can make it private and if i don't need to modify, then I wouldn't. Autoprop is there to remove the noise of having

public string MyProp
    get{return myProp;}
private string myProp;

It removes the noise because this struct is very frequently used. It's purpose is not to make the field inaccessible, IMHO.
3/19/2011 11:37:41 AM #
I enjoyed reading your article on your site. I stumbled on it when I was browsing thru google regarding this specific subject. Good work!
3/22/2011 7:02:44 PM #
What can I say.  This article is pretty good compared to all the junk out there that I have seen.  
3/22/2011 7:04:16 PM #
Great article! So happy to finally see a decent post about tis topic.  I will bookmark it so that I may come back and read more.
3/23/2011 11:40:04 AM #
nice work thank you
Comments are closed