BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Open-source Functional Language Extensions to C# 6

Open-source Functional Language Extensions to C# 6

This item in japanese

Bookmarks

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

Adoption
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.

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

Community comments

  • Clarification

    by Ricardo Rodrigues,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "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

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

BT