Extending C# language, how much effort/gain?

Question

Introduction

As a developer, I'm involved in writing a lot of mathematical code everyday and I'd like to add very few syntactic sugar to the C# language to ease code writing and reviewing.

I've already read about this thread and this other one for possible solutions and would simply like to know which best direction to go and how much effort it may represent to solve only for the three following syntactical issues*.

*: I can survive without described syntactic sugars, but if it ain't too much work and Rube-Goldberg design for simple compilation process, it may be interesting to investigate further.

1. Multiple output arguments

I'd like to write:

 [double x, int i] = foo(z);

Instead of:

 double x;
 int i;
 foo(out x, out i, z);

NB: out parameters being placed first and foo being declared as usual (or using same kind of syntax).

2. Additional operators

I'd like to have a few new unary/binary operators. Don't know much how to define for these (and it seems quite complex for not introducing ambiguity when parsing sources), anyway would like to have something like:

namespace Foo
{
    using binary operator "\" as "MyMath.LeftDivide";
    using unary operator "'" as "MyMath.ConjugateTranspose";

    public class Test
    {
         public void Example()
         {
             var y = x';
             var z = x \ y;
         }
    }
}

Instead of:

namespace Foo
{
    public class Test
    {
         public void Example()
         {
             var y = MyMath.ConjugateTranspose(x);
             var z = MyMath.LeftDivide(x, y);
         }
    }
}

3. Automatic name insertion for static classes

It's extremely unappealing to endlessly repeating Math.BlaBlaBla() everywhere in a computation code instead of writing directly and simply BlaBlaBla.

For sure this can be solved by adding local methods to wrap Math.BlaBlaBla inside computation class. Anyway would be better when there's no ambiguity at all, or when ambiguity would be solved with some sort of implicit keyword, to automatically insert class names when required.

For instance:

using System; 
using implicit MySystem; // Definying for 'MyMaths.Math.Bessel'

public class Example
{
    public Foo()
    {
        var y = 3.0 * Cos(12.0); 
        var z = 3.0 * Bessel(42);
    }

    // Local definition of 'Bessel' function again
    public static double Bessel(double x)
    {
        ...
    }
}

Would become:

using System; 
using MySystem; // Definying for 'Math.Bessel'

public class Example
{
    public Foo()
    {
        var y = 3.0 * System.Math.Cos(12.0); // No ambiguity at all 
        var z = 3.0 * MySystem.Math.Bessel(42); // Solved from `implicit` keyword 
    }

    // Local definition of 'Bessel' function again
    public static double Bessel(double x)
    {
        ...
    }
}

* The compiler may simply generate a warning to indicate that it solved the ambiguity because an implicit solution has been defined.

NB: 3) is satisfying enough for solving 2).

Answer 1

Have you considered using F# instead of C#? In my experience, I have found F# a great fit for scientific/mathematical oriented code, more so than C#.

Your first scenario is covered with tuples; you can write a function like let f a b = (a+b, a-b), which returns a tuple of 2 values directly, you can fairly easily overload operators or add your own, and modules may help you with the 3rd. And F# interoperates fairly smoothly with C#, so you can even pick F# for the parts where it's practical, and keep the rest of your code in C#. There are other niceties which work great for scientific code (units of measure for instance) as well...

Answer 2

I'd be one of the first people to support a mainstream C# that can be extended by users. However - for several reasons (design, time or cost-benefit) I cannot see C# being as extensible as you (or I) want. A C#-derived language I've found that is VERY good for meta-programming and extending functionality/syntax is Nemerle.

Boo is another .NET language with good meta-programming features. However, it is so far removed from C# that I didn't consider it an appropriate answer to this question (but added it for completeness, anyway).