8

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

Community
  • 1
  • 1
CitizenInsane
  • 4,755
  • 1
  • 25
  • 56
  • Miguel de Icaza wanted tuple in C# too http://tirania.org/blog/archive/2009/Dec-23.html – Michael Buen May 27 '12 at 01:42
  • 7
    Effot == lots and lots. Gain == almost zero. Unless you want to be the lone programmer in whatever programming project you pursue, this is a terrible idea. (you'll annihilate tooling support (i.e. Resharper), you'll make any qualified C# programmer suddenly unqualified to use his favorite language, nobody will be able to come in and read your code, no refactorings, the list is endless.) – Kirk Woll May 27 '12 at 01:42
  • "Automatic name insertion for static classes" -- using static function without the class qualifier, supported in Java; I'm not saying it's exactly a good/bad thing though: http://www.deitel.com/articles/java_tutorials/20060211/index.html – Michael Buen May 27 '12 at 01:47
  • 2
    I think they are great ideas. I think trying to extend C# to support them is not. There are other languages out there that build on both the CLR/JVM runtimes ... one of which may be more interesting (or practical) for your purposes. However, the tooling support behind C# should not be overlooked: as much as I prefer Scala (for instance), the ReSharper and VS support for C# puts C# "way ahead" in my daily routine. –  May 27 '12 at 01:51
  • If you want this feature with Dotnet, you should be using the Boo language instead of C#. You can write your library in C# and build syntactic sugar in Boo for it, though tuples are supported in Boo already, as I recall, and a macro or pipeline step could enable your proposed variant. – JasonTrue May 27 '12 at 04:46
  • Yes! Point 3 solved in c# 6.0 :) – CitizenInsane Jul 11 '14 at 18:49

2 Answers2

7

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

Mathias
  • 15,191
  • 9
  • 60
  • 92
  • Having another .net language where I can write mathematical code easily and tied it with the rest of the application in C#, VB or whatever is a nice approach (That's what's I'm currently doing by calling MatlabRuntime from C#, even if a quite heavy process). I'll have a deeper look to F# so see how it can fit with my issues. Thanks :) – CitizenInsane May 27 '12 at 12:29
3

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

Ani
  • 10,826
  • 3
  • 27
  • 46
  • 2
    Oh Nemrele! It suffers from all the same problems I outlined in my comment. C# is not such an awful language that it needs a Coffeescript equivalent. – Kirk Woll May 27 '12 at 01:47
  • 1
    I'm sure the OP wasn't thinking of replacing all the C# code at his workplace with cryptic syntactic sugar (I certainly wasn't). There sometimes are problems or common-use scenarios (think DSLs) that need such extensiblity. One module could leverage it to EXCELLENT use while the rest could be in vanilla C#. Summarily dismissing such questions with opinionated responses seems, to me to be discouraging advancement. – Ani May 27 '12 at 02:17
  • @kirk I agree that allowing for unlimited extensions is going back to C/C++ macros & likes pitfalls (And I already consider that abusing from methods extensions and System.Linq is a nightmare). At least for point 1) and 3) I think this may be useful syntactical sugar that may integrate with mainstream C# and may beneficiate to every developer (whatever their working domain). – CitizenInsane May 27 '12 at 12:48