BT

Open-source Functional Language Extensions to C# 6

by Sergio De Simone on Nov 27, 2014 |

Lang Ext, an open-source library for C# written by London-based Paul Louth, provides a set of helper functions and types that aim to "bring some of the functional world into C#" while trying to look like extensions to the language itself.

Lang Ext tries to extend C# in a few areas where using a functional style can bring some improvements to the language, says Paul:

It is great to see the direction that C# is going in, it's clearly going toward a more centrist position midway between OO and functional. But a few key things won't go away, ever. null, for example, won't ever leave the language. Mutable first won't either. And because of this I'm always trying to think of ways of removing those classes of bugs that hurt the most.

Here is a list of a few of the features of the current release of Lang Ext:

  • Better syntax for tuples: e.g., var ab = tuple("a","b");
  • Fix null references through Option.
  • One-liner lambdas: e.g. var add = fun( (int x, int y) => x + y );
  • Void as a real type: in order to support pure functions that shall always return a value (void isn't a first class value)
  • More convenient syntax for immutable lists and dictionaries, with the aim of fostering their use vs. their mutable counterparts, and list pattern matching.

When asked about the rationale for trying and extending C# instead of, e.g., using F# or Haskell, Paul explains that it is not always possible to switch away from C# in an existing project and that sort of bending C# towards a more functional style can be a reasonable approach.

Over the past few years I've done some Haskell and also we've started creating satellite projects around our core project that are developed in F#. F# has been great to work with, and I love how a few key language decisions can make whole classes of bugs disappear. It's frustrating to run back into those bugs when returning to C#.

One of the drawbacks of Lang Ext is that it is non-idiomatic, although Paul questions the true importance of being idiomatic: "A lot of C#'s idioms are inherited from Java and C# 1.0", all the while "C# as a language is becoming more and more like a functional language on every release."

Rate this Article

Relevance
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Clarification by Ricardo Rodrigues

Hi.
Can you clarify on:

- Fix null references: how os this being addressed ?
- One-liner lambdas: how does this differ from the existing syntax (a, b) => a + b ?
- Void as a real type: what changes/improves ?

This article doesn't explain pros/cons or details the functionality itself.
Thanks.

Re: Clarification by Paul Louth

Hi Ricardo, I'm the author of the project that this article relates to. If you follow the link to the github project all of your questions are dealt with, but in brief:

> Fix null references: how os this being addressed

'null' is mostly used to indicate 'no value' when a function can't return what is asked of it. However the null still allows usage as though there were an actual value of the required type returned. So the contract between the type and the underlying value is broken. Leading to null reference exceptions. By using option types that are structs, it makes it impossible to return null values from a method. It forces the programmer to acknowledge the possibility of receiving a 'no value' return by using pattern matching. This makes the method signature declarative and explicit.

- One-liner lambdas: how does this differ from the existing syntax (a, b) => a + b ?

C# won't allow this:

var func = (a, b) => a + b;

it won't even allow this:

var func = (int a, int b) => a + b;

The library allows for var inference by wrapping the lambda in fun() or act(), e.g.

var func = fun( (int a, int b) => a + b );

Clearly you could write this:

Func<int, int, int> func = (a, b) => a + b;

And that's fine. I personally think the syntax is cleaner when the types are part of the argument list.

- Void as a real type: what changes/improves ?

It allows for usage in generics and makes expression based programming easier. It's simply a first-class 'void'

</int,>

Re: Clarification by James Curran

Paul,
While we have you here answering questions....

The description of Lang.Ext, both here and on the github page, describe the features in isolation, without it being clear how one actually makes use of them in an actual program (e.g., DO I need to derived my classes from a particular base, etc....)

Re: Clarification by Martin Knesl

"It forces the programmer to acknowledge the possibility of receiving a 'no value' return by using pattern matching."

Java forces you to acknowledge the possibility of receiving an exception by forcing you to specify it. Does that mean it's automatically better? A significant number of programmers don't think so.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss
General Feedback
Bugs
Advertising
Editorial
Marketing
InfoQ.com and all content copyright © 2006-2016 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT