C# 3.0 - now with extra hotness!

That all sounds very cool, but I hope the language doesn't end up being too bloated with features that rarely get used.

Looks like they are reinventing Common Lisp. With syntax...

Except the "with syntax"-part I think that's a good idea.

[Edited by - Trap on June 21, 2006 5:17:53 AM]

Very nice

Quote:

Original post by Trap Looks like they are reinventing Common Lisp.

Not yet; they still need to allow you to treat all code as data and write macros. You can call the C# compiler through the Microsoft.CSharp namespace, which isn't quite the same; but the lambda expression trees are certainly a nice step.

LINQ and the expression tree stuff seem to be getting really close to code-is-data, ala Lisp. Obviously they're not there yet, but it's quite clear that they're headed in that direction. I wouldn't be surprised if C# 4.0 was considered "an acceptable Lisp" in the way that Ruby is currently.


One thing to keep in mind is that they're working in an existing environment. They're obviously trying to appeal to C++ programmers as well as those who have found the strengths of Java; they're working against the .Net CLR so there's already a fairly "fixed" target; and they're working to retain close similarity with other .Net languages and of course old versions of C#. I suspect that, without those restrictions, C# would already look a lot more like Lisp. However, given the realities, I see the "slow move" as really just the necessary steps of providing facilities for Lisp-like language features, on top of the existing foundation in .Net. We just get to see the intermediate stages as they release stuff that forms the building blocks for the next step forward.

Quote:

Original post by Beer Hunter Quote: Original post by Trap Looks like they are reinventing Common Lisp. Not yet; they still need to allow you to treat all code as data and write macros. You can call the C# compiler through the Microsoft.CSharp namespace, which isn't quite the same; but the lambda expression trees are certainly a nice step.

Unless I'm mistaken, then this part is exactly (or at least pretty close) to what you are talking about:

"Expression trees permit lambda expressions to be represented as data structures instead of executable code."

Edit: Read ApochPiQ's post.

Adding those known-to-be-good features is probably the best bet for them but on a second thought I would be happier to see MS trying out something new or showing some ingenious solution to a yet unsupported part of programming.

λ# ?

Anyway, quite interesting. I going to spend some time this week end to decipher this.

Regards,

This has been out a while, but this looks like a new version.

If you look at Microsoft Research's page you can find a few research language projects such as COmega. Features like LINQ and the addition of lambda expressions to C# where explored there first. You can see other things they are working on which will probably end up in future revisions of C#, such as join-calculus based concurrency.

C# is gaining features common in functional languages, but it won't become Lisp. There are aspects of Lisp it shouldn't adopt. C# is adopting features from newer functional languages instead, Haskell in particular. Haskell's lead designer works at Microsoft Research, and ideas like software transactional memory from Haskell are being added to C#.

It's good that features commonly associated with Lisp and functional languages in general are being worked into a mainstream language. I agree that C# and .NET could end up being bloated with old features that are no longer used though. The old non-generic containers for example will presumedly stay in the framework (at least for a while), even though there is no reason to use them.

I'm certainly no expert, and haven't used functional languages enough to form a personal opinion, but I am skeptical. I also certainly doubt that the average programmer will somehow become more skilled because good things are available to them; just look at all the C with classes people...

Quote:

Original post by ApochPiQ Microsoft has released some preliminary documentation for their plans for C# version 3.0 (if that link is stale, head over here and click the C#3.0 Language Specification link).

This isn't new news and the draft spec has been out for a while now.

Quote:

Original post by ApochPiQ The document starts right out talking about the goal of making C# capable of functional-style programming. Given the huge success of C# thus far (in terms of adoption rate), it's interesting to see this push. Personally I'm wondering if this might finally be the thing that gets awareness of functional programming "out there" to a large number of mainstream programmers. Of course, the counterargument is that programmers who aren't comfortable with the functional style may well just ignore those capabilities of the language, and go on writing imperative code - as they say, you can write FORTRAN in any language.

One of the features of purely functional languages that make some programmers who have imperative model hardwired to their brains isn't going to be there, C# 3.0 isn't going to enforce referential transparency & immutability. The major hurdle that a programmer who has the imperative model infused in their brain and starts learning to code in purely functional languages is the change in mind set that they have to make because mutation/mutability is disallowed/non existant, there are no imperative loops only recursion and the recursion operators/patterns i.e. fold/l/r, map, zip etc etc.

This isn't going to happen with C# so unless some of these programmers are clueless and don't think for themselves i really don't see them shunning the use of lambda expressions & query comprehensions and everything else that makes them more productive and write less repetitive boiler-plate code in C#/VB.NET.

The level of "functional-style" programing C# 3.0 gives is not much more than what is offered in C++ with standard library containers & algorithms and boost lambda/phoenix 2. When people understand the purpose of boost lambda in relation to the standard library containers & algorithms i've never heard of anyone shun there use other than the reason that it is unpleaseant at times compared to languages that natively support them or the language has a syntax macro system but this doesn't really count and doesn't apply with C# 3.0.

Quote:

Original post by ApochPiQ The cream of the crop though comes towards the end of the document, in the section "26.8 Expression Trees." Anyone with Lisp familiarity will immediately recognize the impact of this statement: "Expression trees permit lambda expressions to be represented as data structures instead of executable code." Gee, I wonder why that sounds familiar [grin]

I personally think there more akin to expression templates if anything and it's a key/vitial ingredient to writing DESLs in C++ just as is the case with boost.lambda. Unless they work with the internals of the VM/compiler but this isn't the case since no changes are made to .NET and C# 3.0 gets converted to C# 2.0 anyways.

Just as with C++ DESL expression template based libraries i susspect a similar if not better support for writing DESL libraries in C# 3.0.

Quote:

Original post by ApochPiQ LINQ and the expression tree stuff seem to be getting really close to code-is-data, ala Lisp. Obviously they're not there yet, but it's quite clear that they're headed in that direction. I wouldn't be surprised if C# 4.0 was considered "an acceptable Lisp" in the way that Ruby is currently.

LINQ is primarily based on query comprehensions which is related to monad comprehensions, i wouldn't be surprised if the work was based on the paper Comprehending Queries which is clearly inspiried and taken further from the paper Comprehending monads. Some of the other components of LINQ are inspiried by haskell libraries and/or research in Haskell which is of no surprise since one of the key players of LINQ is Erik Meijer who has a background in Haskell.

So in actual fact there is probably more inspiration taken from Haskell than from lisp but not completely of-course.

[Edited by - snk_kid on June 21, 2006 9:36:08 AM]

Quote:

Original by Erik Meijer from Lambda the Ultimate ... If you look closely at the new features introduced to C# and Visual Basic in the context of LINQ, you will recognize many familiar concepts that are regularly discussed on LTU ranging from monads, to meta-programming, lambda expressions, XML programming, to the relationship between static and dynamic typing. The LINQ project consists of a base pattern of query operators (compare to the monad primitives) such as Select (map), SelectMany (concatMap), Where (filter), OrderBy (sort), and GroupBy (groupBy) on top of which Visual Basic and C# define query comprehensions (compare to monad comprehensions) that facilitate querying objects, relational data and XML. The C# syntax for query comprehensions is similar to FLWOR expressions, while the Visual Basic syntax stays close to SQL including aggregation. In addition to the language extensions and base operators, LINQ provides two supplementary domain-specific APIs namely DLinq (compare to HaskellDB) for SQL relational data access, and XLinq (compare to HaXml) for XML hierarchical data access. Besides query comprehensions, Visual Basic provides deep XML integration with XML literals and XML late binding on top of XLinq (compare to Haskell Server Pages, XMl, Comega)...

...... Riiiiiight.